Verdikta Bounties

How to write success criteria for a bounty

Last reviewed 24 October 2026

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:

  1. The task description: what to produce, in plain prose.
  2. 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.
  3. The threshold: the pass mark, from 0 to 100.

The jury scores a submission in two phases:

  1. Gates. If any must-pass criterion fails, the score is 0 and the evaluation stops.
  2. 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:

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 ofAsk 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:

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

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:

6. Test before you fund

The terms cannot be changed once the bounty exists, so check them first:

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

Next: follow a real bounty from criteria to payout · FAQ: fees and settlement