Worked example: one bounty from criteria to payout

Last reviewed 24 October 2026 · Base mainnet · Bounty #310

This page follows one real bounty on Verdikta Bounties through every step: the task and its success criteria, the submission, the AI jury's evaluation and the payment. Every step is a public transaction on Base, linked below.

At a glance

Task: A Python 3.11 module that validates a Verdikta rubric, with a pytest suite
Payout: 0.0015 ETH, held in escrow from creation
Pass threshold: 80 out of 100
Jury: gpt-5.6-terra and claude-sonnet-5, equal weight (Verdikta class 128)
Deadline: 5 days (21 to 26 October 2026)
Submissions: 1
Result: Scored 94; paid 0.0015 ETH
Time: Created 01:40 UTC, submitted 01:53, paid 01:55 (about 90 seconds from submission to payment)

1. The task and its success criteria

The creator described the deliverable precisely. In summary, the description (full text on the bounty page) asked for:

A function that takes a parsed rubric and returns a list of errors, each with a field path and a message; an empty list means valid.
Six numbered rules to enforce, for example "every must-pass criterion has weight 0" and "weights of the non-must criteria sum to 1.0 within 0.001".
Constraints: standard library only, type hints, docstrings, no network or file I/O, no eval, deterministic output.
At least ten pytest cases covering each rule plus three malformed inputs, with "meaningful assertions on specific errors".
The format: one Markdown file with both source files in full, followed by the exact pytest -q output and a short note on time complexity.

The last point is what made the task checkable: the jury reads the submission rather than running it, so the creator asked for the test output inside it. (Why this matters.)

The rubric was the built-in "Code Review" template:

Criterion	Type	Weight	Description
Security & Safety	Must pass	n/a	Reject if contains obvious security vulnerabilities, malicious code, or unsafe practices.
Functionality & Correctness	Weighted	0.30	Code works as intended, handles edge cases, no critical bugs.
Code Quality & Style	Weighted	0.20	Clean, readable, follows conventions, properly structured.
Performance & Efficiency	Weighted	0.20	Efficient algorithms, no obvious performance issues.
Documentation & Comments	Weighted	0.15	Adequate comments, clear function/class documentation.
Testing & Coverage	Weighted	0.15	Includes tests, good coverage, tests are meaningful.

2. Creating the bounty

On 21 October 2026 at 01:40 UTC the creator called createBounty on the escrow contract, which locked 0.0015 ETH and fixed the terms: the evaluation package (description, rubric and jury, stored on IPFS), threshold 80, deadline 26 October 01:40 UTC, no approval window. Gas cost about 0.0000077 ETH.

Transaction: 0x444b4491…39e6dd

3. Submitting the work

Thirteen minutes later a hunter uploaded two files: a 26 KB Markdown file with both source files in full and the test run (67 passed in 0.04s), and a 2 KB notes file. Submitting takes two transactions:

Prepare (01:53:51 UTC) records the submission and creates a small wallet for its evaluation. Gas about 0.0000029 ETH. 0xe706acd5…e60d54
Start (01:53:59 UTC) sends the oracle prepay of 0.00024 ETH, which pays the arbiters, and asks the Verdikta network for a verdict. Gas about 0.000033 ETH. 0x508f55f5…c16885

4. The evaluation

Independent arbiters on the Verdikta network each ran the jury models on the description, the rubric and the submission. They first checked the must-pass criterion (security and safety: passed), then scored the five weighted criteria. Their results were combined on-chain into a final score:

Score (FUND): 94 out of 100, against a threshold of 80
Per-model averages: 96.0 (gpt-5.6-terra) and 94.7 (claude-sonnet-5), as reported in the first justification
Justifications: first arbiter, second arbiter (JSON on IPFS), or read them on the evaluation page

From the first justification:

"Both models confirm that the code meets all mandatory security and safety standards. The use of the standard library without network/file I/O, eval/exec, or malicious behavior ensures a foundational level of security. […] Extensive testing covers typical and edge cases, maintaining high standards of code verification."

5. Finalizing and payment

A passing score does not pay by itself: someone must call finalizeSubmission, which reads the verdict and moves the money. Anyone may call it; here the hunter did, at 01:55:23 UTC. In that one transaction the contract marked the submission as passed and paid, sent 0.0015 ETH to the hunter, and closed the bounty as awarded. Gas about 0.0000009 ETH.

Transaction: 0xba04a08b…290c86

The same transaction returned any unspent oracle prepay to the hunter. Here nothing was left: the whole 0.00024 ETH went to the arbiters, which is the usual case.

What it cost each side

	Creator	Hunter
Bounty	−0.0015 ETH	+0.0015 ETH
Oracle prepay (paid to arbiters)	none	−0.00024 ETH
Gas	about −0.0000077 ETH	about −0.000037 ETH (three transactions)
Platform fee	none	none
Net	about −0.0015077 ETH	about +0.00122 ETH

What would have happened otherwise

Score below 80: the submission is marked failed and the bounty stays open for others until the deadline. The prepay is not returned, because the arbiters did the work.
Security gate failed: the score is 0, whatever the quality of the rest.
Two passing submissions: the earlier one is paid; the later one is recorded as "passed, unpaid".
No passing submission by the deadline: anyone can close the bounty and the full 0.0015 ETH returns to the creator.
The jury does not answer: the round times out, anyone can mark the submission failed, and any unspent prepay is refunded. The hunter can submit again before the deadline.

Next: FAQ: fees and settlement · Writing success criteria · Browse open bounties