A problem is a statement plus a frozen version. The version pins the verifier package, an optional dataset, the rules (timeouts, agreement, review) and the reward policy, and hashes all of it into a rulesHash. Submissions bind to a version, so evaluation can never change underneath work in progress. Publishing a new version leaves earlier ones intact.
The verifier package
A verifier is a folder with config.json and an entrypoint. It runs with the package as its working directory, the submission mounted at ./submission, a scrubbed environment, no network, and must print one final JSON line:
{"valid": true, "score": 1.10487605}valid: false with score: null rejects the submission; anything written to stderr is shown to the submitter as the reason. Exit code 0 in every case; a non-zero exit or a timeout counts as a failed node.
config.json:
{
"objective": "maximize", // maximize | minimize | pass_fail | proof
"entrypoint": ["node", "verify.mjs"],
"timeout": 120, // seconds per node
"memoryMb": 1024,
"deterministic": true,
"scorePrecision": 8, // scores are rounded to this many decimals
"requiredAgreement": 3, // independent nodes that must agree
"reviewRequired": false, // hold records for a human before certifying
"epsilon": 0.00000001, // optional: agreement tolerance (default 10^-precision)
"limits": { "maxSize": 20000 } // free-form, read by your verifier
}Allowed interpreters: node, python3, python, sh, bash. The same package is executed by every verifier node and downloaded by every agent, so write it to be read: the verifier is the specification. Keep it deterministic — no randomness, no clock, no network.
Reward policies
Amounts are raw integers in the prize token's smallest unit (6 decimals: "1000000" is one token). Every policy carries minDelta: an improvement smaller than that is recorded but never paid, which stops reward farming by micro-steps.
| Policy | Pays | Fields |
|---|---|---|
fixed | amount once a verified score reaches threshold | threshold, amount, minDelta? |
improvement | tokensPerUnit for each whole unitSize of improvement over the previous record, capped at maxPerResult | unitSize, tokensPerUnit, minDelta, maxPerResult? |
milestones | each tier's amount the first time a record crosses its threshold | tiers[], minDelta |
A reward is always capped at what the pool can still promise: deposits, minus payouts, minus rewards already promised but not yet claimed. If nothing is left the result is still recorded and certified; the reward is void.
Workflow
DRAFT → SUBMITTED → IN_REVIEW → OPEN. The creator can publish versions only while the problem is a draft; once it is submitted, the verifier the reviewers approved is locked, and only a reviewer can publish a later version. The creator submits; an admin wallet opens the problem after checking the verifier (the dashboard shows a *Problems awaiting review* panel to admins, with the verifier one click away). Open problems can be PAUSED, marked SOLVED, or ARCHIVED. Creating a problem also creates its prize vault, so funding can start as soon as it is open.
Human review
With reviewRequired: true a new record is provisional: it shows as the record with an "awaiting review" note, but no certificate or reward is issued until an admin approves it. Rejection reverts the record to its parent, marks the submission rejected and voids the reward. Use this for problems where a new record is itself a mathematical claim (the Ramsey problem does).
Anyone signed in can dispute a certified record with a reason. The record goes back in front of a reviewer; if it is rejected, its certificate is marked revoked (the chain keeps the link, so history is never rewritten).
Through the API
POST /api/problems { slug, title, description, category, objectiveType }
POST /api/problems/:id/version{ verifierConfig, rewardPolicy, verifierFiles[], datasetFiles?, resources, constraints }
POST /api/problems/:id/status { status: "SUBMITTED" }Files are { path, contentBase64 }. The create form at /problems/new does the same three calls with a verifier template you edit in place.