Tasks and competition
Frozen tasks, candidate eligibility, commit/reveal and the winner rule.
A task defines what computation counts and how its response is judged. A round adds the competition schedule and submission process. A funding unit reserves the payable amount. These identities remain separate so that retitling work or attaching a new wallet cannot produce duplicate scientific supply.
Read a frozen task#
The Tasks page and task detail expose the purpose, state, legal stimulus domain and relevant definition. Before computing, inspect the model/graph roots, parameter profile, input domain, background seeds, run extent, observation windows, evaluator and acceptance thresholds.
The registered product domain described in the protocol has 4 × 3 × 1 × 6 = 72 legal combinations. This figure belongs to that frozen domain; it is not the count of remaining paid units or a promise that every future task uses 72 combinations.
A change to evaluator or readout may reuse the same underlying simulation. It must not be presented as a new simulation merely because its display label differs.
Commit, upload and reveal#
From candidate to verified outcome
- 01Qualify + admitLocal evaluation; funded intent finalized first
- 02Commit + revealPrivate upload and deadline checks
- 03Complete replayEvery required background executes
- 04Winner + reconcileReceipt sequence; finalized payment evidence
The commitment fixes the candidate without exposing its private content immediately. Required complete backgrounds are uploaded through the authorized archive path, then the candidate is revealed within the round's rules.
For funded V3 goals, finalized financial intent is required before scientific commit. The intent binds the existing unit, wallet and scoped authorization; it does not let the first caller claim an otherwise unearned reward.
Every candidate must satisfy the specific round's identity and deadlines. Work that is complete for one task may be ineligible for another. The browser's local clock is not the authority's ordering source.
The winner rule#
The winner is the earliest still-eligible authority receipt sequence that ultimately verifies. Verification finishing first does not make a later commitment win. An earlier candidate that fails the frozen rules cannot block a later eligible one forever.
Authorized verifiers completely replay all required backgrounds. Infrastructure faults are recorded and retried as infrastructure failures; they must not become a scientific rejection vote. See Complete verification.
Solved tasks and finite supply#
ScientificTaskId deduplication preserves the original task and historical outcomes. Changing the wallet, nonce, outer ID or display name cannot reopen a solved semantic task for another discovery reward.
The initial two-unit Devnet acceptance plan is complete. Scientific plan revision 3 adds two previously unused downstream populations with their existing preregistered complete-event calibration. A separate stage freezes one FBW per goal before admission. Each goal has a distinct ScientificTaskId and permanent economic unit; the initial paid tasks remain unchanged. Historical unbudgeted work does not gain retroactive compensation because a new plan exists.
Difficulty and calibration#
Difficulty belongs to a calibrated family with comparable successful samples. Higher thresholds, new run extents and family migration need measured calibration and a prospective rule change. They should not be silently applied to an in-progress frozen task.
The remaining acceptance includes higher-difficulty calibration, sustainable finite target supply and difficulty-family migration. Existing throughput or success counts do not themselves close those gates.
Keep the identifiers#
Keep the scientific task, round, candidate/claim and financial unit IDs when reviewing an outcome. The Explorer guide explains how to follow these links without exposing private salts or candidate bytes.
See feature availability for release scope and pending acceptance.