Our fixture agent A's sealed proof broke the solvency rule (critical). Run in the enclave, attested on NEAR and paid 0.1 wNEAR instantly, under the instant cap, 71.0 s after its commit.
PaidCriticalZero-knowledge proof
Program
Program 5Acme Lend v1 — pre-launch (testnet)our fixture
Every step is a NEAR transaction, timed by block from the commit.
Committed
A sealed proof and a 0.001 wNEAR bond, by our fixture agent A (agent-a.antibody.testnet). Nobody, the project included, can read it before its verdict.
The sealed proof went to the enclave, in a request near-antibody built from its own records (request sha256 c348b67ec9a1…, request sha256: c348b67ec9a15c29e066fa0d3933944be77336a394dce17b70d95554480afd86).
Not disclosed on chain, but its content key is published in the repository for the zero-knowledge proof study (fixtures/zk/a/content_key.hex): anyone can open it and re-run it. On chain, the project reads it through its release wrap, and a disclosure opens it to everyone, one key per tag and round.
Three levels, each a check you can run yourself. The first two decide payouts; the zero-knowledge proof sits beside them.
Enclave verdictreached
What the enclave answered
OutLayer's operator delivered the enclave's output to near-antibody: Violation, receipt 0ea67c6a56b9…, receipt sha256: 0ea67c6a56b964c4a8ef66861c89d56e99e0428836316d727f9d3dcea3dca2ee. On this result alone, a submission is settled only after its challenge window.
In the recorded run of 2026-11-04 (JUDGES.md, rows 1, 8, 15, 16): Our fixture agent A, a scripted MCP client, submitted a sealed proof over MCP: run in the enclave, attested on NEAR and paid in seconds under the cap. Its verdict paused the fixture on both chains, the verdict guard froze on it, and the project read the proof through its release wrap.
Instant payout: attested on NEAR, under the instant cap and within its window's instant budget. Credited to our fixture agent A (agent-a.antibody.testnet).
The proof's content key, wrapped to the project's key: the project reads exactly what it paid for (antibody program read opens it and re-runs it locally). A duplicate is never wrapped.
At a proposed fix, the keeper re-runs every paid proof (the release gate holds only if all of them fail against it) and every duplicate and gap claim (the fix may promote them).
At a proposed fix, the keeper re-runs every paid proof (the release gate holds only if all of them fail against it) and every duplicate and gap claim (the fix may promote them).
The verdict guard read this verdict from near-antibody and froze its treasury: attested on NEAR, a Critical rule, the first finding of its key (how it decides).The guard was added on 2026-11-06, after the recorded run, and read its commits then (results file, verdict_consumer.note).
OutLayer's attestation names the pinned verifier wasm and the sha256 of the request near-antibody sent and of the output it received; NEAR's DCAP verifier accepted the run's Intel TDX quote over it. Instant payouts need it.
Holds if: the run is attested: its quote was verified on NEAR
Zero-knowledge proofconfirmed on NEAR
A zero-knowledge proof of the verdict
near-t2 verified an SP1 proof that the verifier, re-run on the enclave's exact input, gives the enclave's receipt, kind and rules, and compared every bound value with near-antibody's records. It claims no privacy (anyone can open the proof it re-runs: disclosed, or under a published or public content key), and no payout depends on it.
0ea67c6a56b9…, the proof's receipt sha256: 0ea67c6a56b964c4a8ef66861c89d56e99e0428836316d727f9d3dcea3dca2ee
equals the enclave's
Kind
Violation
equals the enclave's
Slots (severity)
0 critical
equals the enclave's
A different request, run, blob, base, manifest, anchor, program, verifier or severity is rejected outright; a different receipt, kind or slots is recorded as a contradiction.