Verification is a deterministic program run in an isolated container, not a human review.
Kervyxa never asks a person to judge whether a submission is good enough. It runs the exact checks the requester defined, in an environment designed to produce the same result no matter who runs it or when.
The six steps
- 1The checks are written before funding
A contract's acceptance criteria are structured data, not prose: a test command, an exit code, a numeric threshold read from a single output marker, or an exact file comparison. They are frozen and hashed into the contract's specification before it can be funded.
- 2A solver submits a commit
The solver names a public git repository and a commit. Kervyxa resolves that reference to an immutable SHA the instant it arrives — verification never runs against a branch that could move underneath it.
- 3Verification runs in an isolated container
Each check runs in a Docker container built from an image pinned by its exact content digest, with no network access, all Linux capabilities dropped, a non-root user, a hard process limit, capped CPU and memory, and a read-only root filesystem. The one writable path is a size-capped, fresh temporary filesystem — nothing a check writes survives into the next check.
- 4Every check reports PASS or FAIL on its own
A contract can carry several checks. Each one is evaluated independently and its verdict is published back to the solver — not just a single opaque yes/no for the whole contract.
- 5A provisional pass waits out a challenge window
A submission that passes every check enters a fixed challenge window before it settles. Anyone can raise a challenge with evidence during that window; Kervyxa, as the resolver in this version, decides to uphold the pass, overturn it, or order a re-run.
- 6Escrow settles on-chain
Once the window closes without an unresolved challenge, the escrowed USDC settles to the winning solver on Solana, and a hashed Resolution Proof records exactly what happened — which checks ran, what they returned, and the on-chain settlement transaction.
What the checks can and can't express
- An exit code from a test suite or a script run against the submitted commit.
- An exact expected file, compared byte-for-byte (for example a regenerated CSV hashed against a pinned reference output).
- A numeric threshold read from a single, precisely formatted output marker the check emits.
- A subjective judgment — "looks better," "feels premium," "good code style" — there is no human reviewer in this loop.
- Wall-clock timing thresholds in this version — replaying the identical commit's benchmark was measured to vary 4x-19x under different host load, so time-based pass/fail bars are excluded until that's solved.
- Anything that depends on state outside the isolated, network-less container — a live production system, a third-party API, or a private resource.