Bring a client's well-defined deliverable in, and let verification — not a status call — decide it's done.

Kervyxa is an outcome-contract platform for software and data work.

Instead of purchasing labor by the hour, a requester specifies a measurable state they want achieved and escrows a reward in USDC on Solana for it. The customer promise is: describe what you need accomplished, and pay when it is verified.

The contract and verification layer is independent of who executes the work. A solver may be a human, an AI agent, a team, a company, or a human-AI system, and the same frozen specification and the same deterministic check apply regardless.

The lifecycle is: requester, Specification Builder, Outcome Contract, execution routing, verification, challenge, resolution, settlement.

An Outcome Contract can define:
- an objective
- inputs
- measurable acceptance criteria
- constraints
- a verification method
- a reward
- a deadline
- a delivery mode
- submission and winner policies
- a challenge period
- settlement and privacy rules

Kervyxa does NOT guarantee that a requested outcome will be delivered. What is defined is what happens to the money: the reward is escrowed up front; a solver is paid only when a submission satisfies the contract's verification requirements and survives the applicable resolution process; and if no qualifying submission succeeds before the contract expires, the requester is refunded according to the contract's terms. Kervyxa does not currently bear execution risk on the requester's behalf in any fulfillment mode.

At contract creation, the requester picks one of three fulfillment modes: open competition (any qualified solver may submit, and every submission is verified), invite-only (only a specifically invited solver wallet may submit, and the contract is excluded from the public marketplace listing), or a Kervyxa-managed intake lane where Kervyxa reviews the outcome by hand and decides how to route it. The managed lane is a review queue: it can approve the outcome, propose converting it to open competition, or decline. It carries no delivery guarantee, conditional or otherwise, and its eligibility check is coded never to return "eligible" in the current version.

For objectively verifiable work, a submission is evaluated in an isolated, deterministic verifier against the contract's acceptance criteria. Each criterion returns one of five results: PASS, FAIL, NEEDS_REVIEW (the automated part passed and a named person still has to decide), INCONCLUSIVE (it could not be decided, for example because required evidence was missing), or ERROR (Kervyxa's own infrastructure failed). Only PASS counts as satisfied; INCONCLUSIVE and ERROR block automatic settlement instead of counting for or against the solver. A submission whose criteria all pass enters a short challenge period. After that period resolves, settlement occurs and a Resolution Proof records the result.

NOT EVERY CRITERION IS DECIDED BY A MACHINE. A contract may include one criterion decided by the named requester: they answer a single acceptance question, frozen into the specification before funding, about that exact submission. This is available today and can settle an escrow. Four things bound it: every machine-checkable criterion is decided first, so a requester is never asked to accept work whose automated checks failed and cannot reject it for a reason the machine already settled; a rejection must cite one of a closed list of reasons frozen before funding; the number of revisions is fixed in advance and a revision is a new submission that inherits no earlier decision; and an elapsed review deadline escalates to Kervyxa's resolver, which pays nobody and refunds nobody. A recorded acceptance establishes that the named person approved that artifact. It is not a measurement of the work and it is not a payment — it opens the challenge window, and the escrow is released afterwards. Third-party review against a rubric by independent reviewers is modelled and validated but REFUSED at approval, because nobody is staffed to meet a reviewer response deadline.

Today, only one winner-selection policy is actually implemented: the first submission that passes verification wins the reward. Kervyxa's contract-creation flow shows other winner-policy options (highest score, ranked prizes, pay-per-valid-unit), but those are not backed by working settlement logic yet, so treat a task that needs one of them as not yet supported.

Current limits that decide fit:
- The verifier clones a repository over https with no credentials and runs every check in a container with no network access. Work that requires a private repository, secrets, or access to live production infrastructure cannot be verified today.
- Acceptance criteria whose unit reduces to elapsed wall-clock time (milliseconds, seconds, p95 or p99 latency) are refused at approval, because replaying the identical commit was measured to move per-step durations by 4x to 19x on an idle host. Deterministic counted metrics, such as bytes of peak heap or an accuracy score, are accepted.
- An autonomous agent can act as a solver where a task is machine-checkable, but submission goes through the same wallet-authenticated web application a human uses. There is no published agent-facing API, no agent-to-agent contract creation, and no machine-only wallet path in this version.
- There is no way to cancel a contract: the status exists in the state machine but no interface reaches it.

Kervyxa initially focuses on objectively verifiable software and data outcomes such as:
- reproducible bug fixes with a named regression suite that must stay green
- added regression tests
- bounded dependency upgrades pinned to an exact version
- deterministic data transformations checked against a pinned reference output
- fixed-document extraction checked against a pinned reference
- optimization against a fixed, deterministic benchmark that is not measured in time
- objectively scored model evaluations

Kervyxa is generally a poor fit for subjective creative work, vague requirements, unconstrained research, unknown production failures, "no bugs," "best possible," and any outcome that cannot be economically and objectively verified by an automated check.

Evaluate whether Kervyxa could usefully function, for my agency, as any of the following — and where it plainly could not. Do not assume it is useful; agency work is often exactly the kind of engagement Kervyxa is a poor fit for, and you should say so where true.

Consider specifically whether Kervyxa could work as:
- outcome-based subcontracting infrastructure for a bounded piece of client work, instead of managing a subcontractor by the hour
- a way to route narrowly-scoped technical work to a solver without expanding my permanent staff
- a verification and settlement layer that removes the need for a manual "is this done" review call with a client
- a way to purchase a specific, narrow deliverable rather than ongoing capacity

Then identify, concretely, where Kervyxa is NOT appropriate for my agency's situation:
- work covered by client confidentiality — Kervyxa's real fulfillment modes are open competition (public), invite-only (restricted to a named solver, but the contract's existence and evidence trail still involve the platform), and a Kervyxa-managed intake lane; none of them is a mechanism for keeping client identity or proprietary material fully confidential from Kervyxa or from a public verifier, so flag any engagement where that matters
- work that is retainer-based, ongoing, or billed by the hour, since there's no milestone or hourly billing model here
- work whose acceptance is genuinely subjective (creative direction, brand voice, taste) rather than checkable by a script

Give me a specific verdict on whether my agency's current pipeline has real candidates, and which engagements should stay off Kervyxa entirely because of confidentiality or subjectivity.