An Outcome Contract is a frozen, checkable definition of a result, backed by escrow.
Everything on Kervyxa — the Specification Builder, verification, the challenge window, settlement — exists to move one Outcome Contract through its lifecycle. Understanding this one object is enough to understand the whole product.
What's inside a contract
- Objective
- A plain description of the result being bought.
- Repository + commit
- The public git repository and (for a submission) the exact commit SHA being verified.
- Acceptance criteria
- The executable checks that decide PASS/FAIL — test, exit_code, file_assertion, numeric_threshold, and regression criteria.
- Reward
- The USDC amount escrowed for the winning solver.
- Deadline
- The point after which an unfunded or unsolved contract can be refunded.
- Submission policy
- PUBLIC (anyone may submit) or INVITED (one pinned solver wallet may submit).
- Winner policy
- FIRST_VERIFIED_PASS — the first submission whose pass survives the challenge window wins the whole reward. It is currently the only winner policy implemented.
- Specification hash
- A SHA-256 of the settlement-critical fields above. Change any one and the hash changes.
The lifecycle
Requester → Specification Builder → Outcome Contract (frozen + hashed) → execution routing → verification → challenge → resolution → settlement. Concretely: the contract is funded in USDC escrow, routed to whoever may submit against it, and a submission goes through deterministic verification; a provisional pass sits in a challenge window; Kervyxa resolves any challenge; a Resolution Proof is generated; escrow settles to the winner on Solana. See how verification works for the step that decides PASS or FAIL, in detail.
Execution routing is one stage of that lifecycle, not the product. A contract can be routed to one invited solver wallet (a trusted expert, a subcontractor, an autonomous agent), or opened to public competition; a hand-reviewed Kervyxa-managed lane exists as an intake queue. The specification, the hash, and the check that decides PASS or FAIL are identical in every case — which is why the routing decision can change without changing what is being bought.
The lifecycle has two endings, not one. Payment is released only for a verified result; if no qualifying submission succeeds before the contract expires, the escrow is refunded to the requester according to the contract's terms. An escrow resolves exactly once — a settled escrow can never be refunded, and a refunded one can never later settle.
Once approved, the contract is frozen
A set of settlement-critical fields — the objective, the repository and base commit, the full specification and acceptance criteria, constraints, the verification method, the reward amount and currency, the deadline, the submission policy, an invited solver's wallet if any, the winner policy, and the challenge period — cannot change after approval without changing the contract's specification hash. This is what makes a Resolution Proof trustworthy: the checks a solver was actually verified against are provably the same ones the requester approved.
When an Outcome Contract is the wrong shape
- The result can be reduced to a test, an exit code, an exact file comparison, or a numeric threshold read from one marker.
- You can name a concrete repository, commit, and deadline before work starts.
- You're comfortable with escrow, a challenge window, and Kervyxa acting as the single resolver in this version.
- Acceptance depends on subjective judgment — taste, brand voice, "looks better" — with no automated check possible.
- The work needs access to private production infrastructure or long-lived credentials no unknown solver should hold.
- The task is genuinely open-ended research with no fixed, checkable end state to freeze into a specification.