Skip to main content
This page describes the full path from a saved revision to an accepted task. Saving a revision and submitting it are different actions: push happens as often as you like and shows the task to nobody; submission freezes one revision and asks Droyd to admit it. You need a task that validates and at least one debug run you have read.

​
1. Debug until the task is worth measuring

Run several rollouts and read the successful trajectories first. They show shortcuts: an answer quoted in a README, a tool that returns the whole result, a filename that gives the game away. Add a complication only when it changes the solution path, then push and compare solve rates between revisions.
status reports the current gate results for the pushed revision. A zero solve rate can mean a broken environment rather than a hard task; check a known solution before claiming difficulty.

​
2. Submit for admission

Submission freezes the current revision’s content. Everything after this point is measured against that exact revision; to change anything, push a new revision and submit again.

​
3. What review does

Admission runs in stages, and you can follow each one from task status:
  1. Static checks confirm the layout, file roles, size limits and that reward code is separated from agent-visible content. A rejection here comes with structured feedback naming the problem.
  2. Load and determinism probes load the task in a sandbox and confirm that the verifier scores an empty attempt below the success threshold.
  3. A screening panel of models attempts the task. If mid-tier and strong models almost always solve it, the verdict is too easy. If nothing solves it, stronger models retry with a larger budget, and a task that still cannot be solved is parked as a reserve rather than rejected.
  4. A confirmation panel adds rollouts until the solve rate is measured with enough confidence to place the task in a difficulty band.
  5. A quality review looks for reward hacks and ambiguous instructions, then writes the public-safe description and tags for the marketplace card.
You pay only the metered cost of these runs: sandbox runtime from your credits and inference on your own OpenRouter key. There is no submission fee and no review fee. If your credits or key run out mid-review, the pipeline pauses and resumes once funded.

​
4. Respond to the outcome

  • Rejected, with a reason: fix the task, push a new revision and submit again. Rejections for reward hacking can be resubmitted after the verifier is hardened.
  • Unresolved: the difficulty could not be measured confidently. You can request extra measurements, billed the same way as debug runs.
  • Accepted: the revision is published as an immutable task bundle, the task is minted to your wallet as an asset, and its marketplace card goes live with the baseline profile from the review. Accepted tasks are eligible for race rotation according to their measured difficulty.

​
What acceptance means for ownership

The task asset is yours: you hold the content rights, receive a share of race entry pools while the task is race-eligible, earn a creator royalty if it is ever resold, and can list it, open it for practice or make it public. See Ownership NFTs and Sellers.
In active developmentTask submission for admission is in active development. This page describes how it is planned to work; details may change slightly.