For freelancers

Get paid the moment your work passes, not when a client feels satisfied.

Kervyxa is a place to solve Outcome Contracts: work whose acceptance is written down as executable checks before you start, and paid in escrowed USDC the moment a Docker-isolated verifier confirms a pass. No scope negotiation after delivery, no invoice chasing — the reward is already locked in the contract's escrow before you submit a commit.

Browse open outcome contractsAsk your AI if this fits →
Concrete examples

What this looks like

Fix a reproducible bug

The contract names a failing test or reproduction script. You submit a commit; the verifier runs the exact command the requester defined. Pass, and the escrow settles to you.

Bounded dependency upgrade

"Upgrade package X from v2 to v3, pinned to that exact version, with the existing test suite green and no other dependency moved" is a real contract shape — the acceptance criteria are the test run's exit code and the lockfile, nothing subjective.

Deterministic data transformation

A JSONL-to-CSV conversion with a pinned reference output is exactly the kind of task Kervyxa can verify byte-for-byte — no client review cycle required.

Competing submissions can both win a look

Kervyxa resolves FIRST_VERIFIED_PASS: the first passing submission takes the window, but a second submission is deferred, not discarded, and gets its turn if the first is overturned.

Who this is for, and who it isn't

Kervyxa is a fit when
  • The work has an objective, checkable definition of done: a failing test that should pass, a numeric threshold, an exact expected output.
  • You would rather be judged by a machine-run check than a client's subjective read of your delivery.
  • You want the reward secured in escrow before you write a line of code.
  • You're comfortable working against a public git repository and a specific commit.
Kervyxa is a bad fit when
  • The brief is subjective — "make the design feel more premium", "just make it better" — with no way to encode acceptance as a command and an exit code.
  • You want ongoing hourly work, retainer billing, or milestone-based project management. Kervyxa has no hourly billing, milestones, or messaging today.
  • The repository must stay private. The verifier clones over https with no credentials, so it can only check a repository that is readable without authentication — an invite-only contract restricts who may submit, not what the verifier can read.
  • You need scope to be negotiable mid-engagement. The contract's specification is frozen once approved; changing it changes what's being paid for.

Ask your AI whether this fits

Let your AI find the fit.

Give your AI the Kervyxa model and let it identify which of your real tasks belong here.

Ask your AI which of your clients belong here

Your AI already knows your client history. Hand it the Kervyxa model and let it judge — client by client — whether escrow and verification reduce real friction, or whether a given relationship is better left off any marketplace entirely.

Generated prompt preview
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.

Analyze whether Kervyxa would actually help my freelance work. Do not assume it is beneficial — most of what I do may not fit, and you should say so plainly where that's true.

Using what you know about my current and recent client relationships and project history, reason through:
- whether moving an existing client relationship through Kervyxa (as an Outcome Contract) would add real value, or would just add process for no benefit
- whether specification, escrow, objective acceptance criteria, verification, challenge handling, or settlement would actually reduce friction I currently have, or whether my current friction is somewhere else entirely (communication, scope creep, trust) that Kervyxa doesn't touch
- which of my client projects, if any, are suitable candidates — and be specific about why
- where competition for a contract should NOT be used, because the relationship or the work depends on it being me specifically who does it
- whether private, direct execution outside any marketplace is actually the more appropriate model for a given relationship
- whether the platform fee would be justified by a real reduction in payment risk (nonpayment, scope disputes) or scope risk (undefined "done"), or whether that risk was already low enough that the fee is just a cost with nothing to show for it

Give me a direct verdict per candidate project: use Kervyxa, don't, or it depends on [specific condition]. If nothing in my current work is a good fit, say that instead of forcing a recommendation.