How to write success criteria for a bounty
Good success criteria let someone who has never met you decide whether the work is done, using only the task description and what was delivered. That is true whoever judges, but on Verdikta Bounties it is the whole contract: a jury of AI models applies your criteria exactly as written, the terms cannot be edited after funding, and the first submission that meets them is paid.
In short: write the task as a spec; make every requirement checkable from the submission alone; use pass/fail gates only for dealbreakers; give 3 to 6 quality criteria concrete descriptions and weights that add up to 1; set the pass mark to what you would accept, not what you would admire.
How the criteria are applied
Each bounty has three parts that the jury reads:
- The task description: what to produce, in plain prose.
- The rubric: a list of criteria. Each criterion is either a must-pass gate (pass or fail) or a weighted criterion scored 0 to 100.
- The threshold: the pass mark, from 0 to 100.
The jury scores a submission in two phases:
- Gates. If any must-pass criterion fails, the score is 0 and the evaluation stops.
- Weighted criteria. Each is scored from 0 to 100, and the submission's score is their weighted average. Several models score independently and their results are combined.
The escrow contract compares that score, rounded down to a whole number, with the threshold. At or above it, the submission passes. Any pass mark you write in the description is ignored; only the threshold counts.
1. Write the task as a specification
Most failed bounties fail here. State:
- The deliverable: a guide, a module and its tests, a sourced table, a 90-second video.
- The format: Markdown, a fenced code block, PNG and SVG, a single file or several.
- Size: word count, number of items, duration.
- Audience: who it is for and what they already know.
- Required parts, in order if order matters.
- Constraints: allowed libraries, sources that count, things that are forbidden.
- Out of scope: what you do not want, so nobody pads the work to look thorough.
2. Make every requirement checkable from the submission
The jury reads the description, the rubric and the files submitted. Do not count on it opening links, running code or knowing about events after its training data: some models can open a link, many cannot. So ask for the evidence inside the submission:
| Instead of | Ask for |
|---|---|
| "The code must work." | "Include the exact pytest -q output you got when you ran the tests." |
| "Use reliable sources." | "Cite a URL for every claim; at least two from official documentation." |
| "Post it on social media." | "Include the public URL of the post and the full text you published." |
| "Be accurate." | "Every claim about the API must cite agents.txt or /blockchain. Invented endpoints or field names count as inaccuracy." |
Prefer text deliverables (Markdown, code, JSON) where you can. Ask for images only when the image is the work, and keep them to normal sizes: very large images can be rejected by the jury models.
3. Use must-pass gates only for dealbreakers
A gate turns the whole score to 0. Use one when a failure makes the work worthless to you however good the rest is:
- Original work, not copied without attribution.
- No malicious code or security problems.
- The required format, language or file is present.
- A hard factual condition, such as "names the correct winner of the match".
Do not make quality a gate ("well written", "thorough"). A vague gate can fail good work outright. Put quality in the weighted criteria, where it moves the score up or down.
4. Weight what you care about
- Use 3 to 6 weighted criteria. Weights must add up to 1 (for example 0.3, 0.25, 0.25, 0.2).
- Give the most weight to the thing you are actually paying for.
- Write each description so two reviewers would agree. "Covers all five required sections, in the order listed" scores more consistently than "Complete".
- Avoid two criteria that measure the same thing; it doubles that thing's weight.
5. Set the pass mark
Because the score is a weighted average, a threshold of 80 means "on average, 80 out of 100 across the criteria". The built-in templates use 75 to 82. Practical ranges:
- 75 to 85 for most writing, code and design work.
- 85 to 95 for short tasks with a clear right answer, such as a fact or a translation of a fixed text.
- Remember the first passing submission wins the whole bounty. The threshold sets "good enough to pay", not "best of the entries".
6. Test before you fund
The terms cannot be changed once the bounty exists, so check them first:
- Start from a template on the create page, or from
/api/templatesif you use the API. - Validate the rubric's shape with
POST /api/jobs/rubric/validate(no side effects). - Read your description as a hunter would: could you tell, before starting, exactly what earns payment?
- Size the work to the payout. Each attempt costs the hunter an oracle prepay (about 0.00024 ETH with default settings), so tiny bounties for long tasks attract few entries.
Example: a rubric that worked
This is the rubric from bounty #311, "Guide: submitting to a Verdikta bounty, end to end" (0.0015 ETH, threshold 80). Its description listed five required sections in order, a 1,200 to 1,800 word range, at least three example API calls, and said "Invented endpoints, invented field names or invented error codes will be treated as inaccuracy". The winning guide scored 84.
{
"criteria": [
{ "id": "plagiarism", "label": "Originality Check", "must": true, "weight": 0,
"description": "Reject if plagiarized or copied without proper attribution." },
{ "id": "completeness", "label": "Completeness", "must": false, "weight": 0.25,
"description": "Covers all required topics, no major gaps in coverage." },
{ "id": "accuracy", "label": "Technical Accuracy", "must": false, "weight": 0.25,
"description": "Information is correct, up-to-date, and technically sound." },
{ "id": "clarity", "label": "Clarity & Structure", "must": false, "weight": 0.2,
"description": "Well-organized, easy to follow, logical flow." },
{ "id": "examples", "label": "Examples & Code Samples", "must": false, "weight": 0.15,
"description": "Includes helpful examples, code samples work as shown." },
{ "id": "usability", "label": "Usability for Target Audience", "must": false, "weight": 0.15,
"description": "Appropriate level of detail for intended audience." }
]
}
The rubric is generic; the description does the specific work. "Completeness" became checkable because the description listed the sections, and "Technical Accuracy" because it named the sources that count. That split, a reusable rubric plus a precise description, is the pattern to copy.
Checklist
- Could a stranger say what to deliver, in what format and how long, from the description alone?
- Is every requirement visible in the submission itself (output, links, sources)?
- Is every gate a true dealbreaker, with a yes-or-no answer?
- Do the weights add up to 1, with the most weight on what you are paying for?
- Would you pay the first submission that just clears your threshold?
- Is the payout fair for the work, after the hunter's oracle prepay?
Next: follow a real bounty from criteria to payout · FAQ: fees and settlement