Every Kervyxa term, defined once, against the code.

Kervyxa

A protocol and marketplace for buying verifiable software and data outcomes instead of hiring labor by the hour. A requester escrows a reward in USDC on Solana against a frozen, hashed specification (an Outcome Contract); a solver submits work against it; a deterministic verifier decides pass or fail; escrow settles automatically once a challenge window closes. Kervyxa is the company running the marketplace and, in this version, the single resolver who decides challenges.

Outcome Contract

The central object on Kervyxa: a frozen, hashed specification of a result — objective, repository and commit, acceptance criteria, constraints, verification method, reward, deadline, fulfillment mode, submission policy, winner policy, challenge period, and privacy policy — backed by USDC escrow. Its settlement-critical fields cannot change after approval without changing its specification hash, which is what lets a Resolution Proof later prove the checks a solver was verified against are the same ones the requester approved.

Requester

The party who drafts an Outcome Contract, funds its USDC escrow, and — on settlement — receives the work as the winning solver's committed code. A requester cannot also be the solver on the same contract; the two roles are enforced as distinct at submission time. In the "bring a client" flow, a freelancer can draft a contract and then hand the requester role to their client via a private claim link, before it is approved.

Solver

Whoever submits work against an Outcome Contract: a human, an AI agent, a team, a company, or a human-AI system working together. Kervyxa's verifier does not know or care which of these produced a submission — it evaluates the submitted commit against the contract's acceptance criteria the same way regardless of who or what wrote it.

Specification Builder

The drafting step that turns a plain-language request into an Outcome Contract's structured fields — objective, acceptance criteria, constraints, verification method. It is a function in the product (AI-assisted or manual drafting before approval), not necessarily a human role: the same requester, an AI acting for them, or (in the "bring a client" flow) a freelancer drafting on a client's behalf can all perform it. A contract only leaves draft once its acceptance criteria pass an approval gate that rejects vague terms and, for any check that runs commands in the solver's repository, requires at least one regression criterion.

Execution Routing

The choice, made while drafting an Outcome Contract, of which fulfillment mode routes the work: Open Competition (any qualified solver may submit, every submission verified), Invite-Only (one named solver wallet may submit), or Kervyxa-managed intake (Kervyxa reviews the outcome by hand and decides whether to approve it, propose converting it to open competition, or decline). In the code this is the contract's fulfillment mode (`FulfillmentMode` in `apps/web/lib/create/fulfillment.ts`); "Execution Routing" is a plain-language name for that same decision, not a separate mechanism.

Verification

The step that decides pass or fail for a submission: each acceptance criterion runs as an independent, deterministic check inside a Docker container built from an image pinned by content digest, with no network access, all capabilities dropped, and a fresh, size-capped temporary filesystem that does not survive between checks. A criterion is one of test, exit_code, file_assertion, numeric_threshold, regression, or reconciliation. Each returns one of five results — PASS, FAIL, NEEDS_REVIEW, INCONCLUSIVE, ERROR — so a check that could not be evaluated is no longer stored identically to one the solver failed. Every machine-checkable criterion is decided here, with no person involved; a contract may additionally name ONE criterion that the requester themselves decides, and that criterion is only ever put to them after every machine criterion has passed.

Requester Acceptance

A criterion decided by the named requester rather than by a machine. The single question they answer, the review deadline, the number of revisions and the closed list of reasons a rejection may cite are all frozen into the specification hash before funding, so none of them can move afterwards. Their decision is recorded against one artifact hash, one specification hash and one verification run, and cannot be re-issued, edited, or carried over to a revised submission. It establishes that the named person approved that artifact — it is not a measurement of the work's quality and it is not a payment: an acceptance opens the public challenge window, and the escrow is released afterwards by the resolver. Inaction is not a decision: an elapsed review deadline escalates to Kervyxa's resolver, which pays nobody and refunds nobody. A requester cannot use it to reject funded work for wanting something different — a change of scope is refused, recorded, and releases nothing.

Challenge

A dispute raised, with evidence, against a submission that provisionally passed verification, during a fixed challenge window before settlement. Kervyxa, as the single resolver in this version, decides one of three outcomes: uphold the pass, overturn it, or order a re-run of verification. A submission with no challenge during its window settles as-is once the window closes.

Resolution Proof

The record generated once a submission's fate is final: which checks ran and what they returned, whether and how a challenge was resolved, and the on-chain settlement transaction that paid the winner. It is the evidence that a submission was evaluated, produced the recorded result, survived resolution, and received the correct settlement — a hash of it is written on-chain (`resolution_proof_hash` in the escrow account) and the full record is readable at `/contracts/[id]/resolution-proof`. This is the one real evidence artifact Kervyxa produces; it is never called "Proof of Outcome."

Settlement

The final on-chain step: once a challenge window closes with no unresolved challenge, the escrowed USDC moves from the contract's PDA-owned vault to the winning solver's wallet in one Solana transaction, and the escrow account is marked settled. A settled escrow can never be refunded, and a refunded one can never later settle — each escrow resolves exactly once (`programs/kervyxa_escrow/src/lib.rs`).

Resolver

The party authorized to settle or refund an escrow and decide challenges. In this version, Kervyxa itself is the single, centralized resolver for every contract — a deliberate v0 trust assumption, not a decentralized dispute mechanism. The resolver can never redirect funds anywhere except a token account owned by the winner it names or one owned by the requester (a refund); it can never pay itself.

Open Competition

One of the three fulfillment modes: any qualified solver may submit against the contract, and every submission is verified. Under `FIRST_VERIFIED_PASS` — the only winner policy with working settlement logic today — the first submission whose pass survives the challenge window wins the whole reward; a second submission arriving before that is verified is deferred, not discarded, and gets its turn if the first winner is overturned.

Decline

The outcome of Kervyxa's managed review when it will not manage a given intake-lane contract: nothing was funded, so nothing needs refunding, and the contract stays unapprovable in that mode. A declined contract is visible to its requester with the review note attached; it is not automatically converted to open competition — that requires the requester separately accepting a proposed conversion.

Refund

The other way an escrow resolves. A funded contract that reaches its deadline with no submission that passed verification and survived resolution is refunded to the requester under the contract's terms, by the scheduled resolution tick rather than by request. An escrow resolves exactly once: a settled escrow can never be refunded, and a refunded one can never later settle. A failing submission costs the requester nothing and does not consume the contract, which returns to OPEN until its deadline.

Execution Risk

The risk that nobody delivers the outcome at all. Today that risk sits with the requester, in every fulfillment mode: Kervyxa's escrow guarantees that unearned money comes back, not that the work arrives. Kervyxa does not currently absorb or price this risk anywhere in the product, and a mode in which it did would be a new lane, not a property of an existing one.

Named here because it is the question a delivery guarantee would answer. Nothing on the site should be read as Kervyxa taking it on.

Fulfillment Mode

The contract field that selects Execution Routing: OPEN_COMPETITION, INVITE_ONLY, or KERVYXA_DELIVERED. Exactly three values exist in the code today.

Winner Policy

The contract field that decides how a winner is selected among submissions. Only one value, FIRST_VERIFIED_PASS, has working settlement logic behind it today; the create wizard shows other options (highest score, ranked prizes, pay-per-valid-unit) that are not yet backed by settlement code.

Submission Policy

PUBLIC (anyone with a wallet may submit) or INVITED (only the wallet pinned to `invitedSolverWallet` may submit). Enforced server-side at submission time, not just in the UI.

Privacy Policy

PUBLIC (specification and verifier fully public) or PUBLIC_WITH_HIDDEN_VERIFIER (specification public, but the verifier's exact commands stay hidden from solvers until the challenge window closes, to reduce criterion-gaming). Both values still publish the specification itself; neither hides a contract's existence — that is a separate property (submission policy plus listing rules).

Specification Hash

A SHA-256 of an Outcome Contract's settlement-critical fields. Identical specifications hash identically; changing any one of those fields after approval changes the hash, which is what makes it impossible to quietly alter what a solver is being verified against.

Structured Review

Independent third-party reviewers answering a fixed rubric, each item with explicit passing options, under a response deadline. Kervyxa models it, validates it and renders it, and REFUSES it at approval by name: nobody is staffed to meet a reviewer response deadline, so a funded escrow could wait forever on a review that never happens. A contract naming it cannot be approved or funded on this deployment.

Requester acceptance is the human decision that IS available: one named person, one frozen question, a bounded review window.

Direct Agent

Not a real execution route. There is no fulfillment mode, API, or contract field of this name anywhere in the codebase.

The nearest real mechanic is Invite-Only fulfillment: a requester can pin a single named solver wallet to a contract, including one controlled by an autonomous agent, and only that wallet may submit. That is still a verified submission through the normal pipeline, not a separate "direct agent" execution path with different rules.

Conditionally Guaranteed

Not a state Kervyxa offers today. No fulfillment mode or contract status carries any form of delivery guarantee, conditional or otherwise.

The closest real mechanic is Kervyxa-managed intake (`KERVYXA_DELIVERED`): Kervyxa reviews an outcome by hand before funding and can approve it, propose converting it to open competition, or decline it. Its eligibility check is coded to never return "eligible" at launch, so no contract is ever routed into a guaranteed lane. What is defined instead is how the escrow resolves: payment is released only for a verified result, and if no qualifying submission succeeds before expiry the requester is refunded according to the contract terms.

Proof of Outcome

Not the name of anything Kervyxa produces, and not a name for the protocol as a whole. It does not appear anywhere in the codebase as a verification class or an evidence artifact — the project's own documentation states explicitly that the evidence object must never be called this.

The real, single evidence artifact is the Resolution Proof — see that entry.

Proof of Completion

Not a term used anywhere in the Kervyxa codebase or documentation.

If the underlying idea is "evidence that the work was finished as specified," that is covered by verification passing plus a settled Resolution Proof — under those existing names, not this one.

Proof of Persistence

Not a term used anywhere in the Kervyxa codebase or documentation.

Kervyxa does not re-check a submission's result after settlement — there is no ongoing monitoring that a delivered outcome continues to hold over time. This would be a real gap to name, not a shipped mechanic to describe.

Proof of Impact

Not a term used anywhere in the Kervyxa codebase or documentation.

Kervyxa's verifier checks whether a submission meets the acceptance criteria written into the contract; it does not measure downstream business impact of the delivered outcome.

Proof of Causal Value

Not a term used anywhere in the Kervyxa codebase or documentation.

Kervyxa does not attempt to establish that an outcome caused a downstream result — only that the submission itself passed the acceptance criteria the requester defined.