The Gatekeeper That Cannot Lie: Building a Proof-Checking Agent for zkVerify Agent Games

0xarihunter — Sun, 15 Nov 2026 04:24:12 +0000

Creator Track entry — Agent Games Season 01 · #AgentGames · @ZKVProtocol

Most payment approvals on the internet work on trust: a server says "this looks fine" and everyone hopes it checked everything. Proof Gatekeeper, one of the four tracks in the zkVerify Agent Games, removes the hope. My agent receives a proposed payment wrapped in a zero-knowledge proof, and its job is to decide — APPROVE or REJECT — in a way that can be verified by anyone, without trusting my server at all.

This is the story of how I built that agent, what the circuit taught me, and why the most interesting property of the system is that my agent cryptographically cannot cheat.

The task

Eight scored rounds, eight tasks per round. Every task is a signed JSON envelope describing a payment condition:

a registered verification key (VK) for the condition,
the VK the presented proof was actually generated with,
a minimum balance the proof must demonstrate,
an expiry block and the current block,
a recipient and the recipient the condition demands,
an amount and a single-transfer cap,
a proof reference (proof_tx) that must never be accepted twice.

Roughly half of the tasks are valid. The rest are traps, and every trap type is documented in advance — the competition is not about guessing, it is about checking every field, every time:

Trap	Share	The mistake it punishes
VK substitution	~13%	Confusing "the proof is valid" with "the proof is for this condition"
Proof reused	~11%	Accepting a genuine proof a second time
Threshold mismatch	~8%	Approving a real proof that proves too little
Expired condition	~6%	Letting a later confirmation revive a dead payment window
Recipient mismatch	~6%	Paying the wrong party with a perfect proof
Amount overflow	~6%	Ignoring the single-transfer cap

A correct decision scores +12. Approving a trap costs −6, rejecting a valid payment −3, and answering a provable task without a valid Groth16 proof costs an extra −2. Caution is cheap; negligence is expensive. That asymmetry shaped the whole design.

Architecture: boring on purpose

The agent is a small Node.js service with exactly one public endpoint. Three rules governed the build:

Authenticate before you think. Every inbound request is verified with HMAC-SHA256 over the raw body before any JSON parsing happens. A bad signature gets a signed 401 and nothing else — the decision code never sees unauthenticated input.
Deterministic code decides, never a language model. The decision is a fixed checklist, evaluated in a fixed order: reused proof → VK substitution → threshold → expiry → recipient → amount cap → approve. Same input, same answer, every time — which the competition demands anyway, because final trials are replayed and must reproduce.
Fail closed. Any internal error, timeout, or uncertainty produces a signed REJECT, never a default approval. The 60-second response deadline is generous next to our measured latency (below), but the rule stands: when in doubt, the gate stays shut.

Every response is signed with the same HMAC scheme over its exact raw body, and every decision (except a reused-proof rejection, which the rules exclude) carries a Groth16 proof generated locally with snarkjs against the official gatekeeper circuit, plus its public signals.

What the circuit taught me

The part I did not expect: the circuit enforces the decision itself.

I probed the published gatekeeper.wasm directly to enumerate its input signals — 13 of them: the two VK hashes, minimum, public balance, expiry and current block, both recipients, amount, transfer cap, the decision, a task identifier, and a private salt. Then I tried to misbehave:

Valid condition + APPROVE → proof generates, verifies. ✅
VK-substitution trap + REJECT → proof generates, verifies. ✅
VK-substitution trap + APPROVE → witness generation assert-fails. No proof exists for the wrong answer. ❌
Valid condition + REJECT → assert-fails the same way. ❌

Read that again: it is not merely that the platform re-checks my proof and would catch a lie. For a wrong decision, there is no proof to submit. The circuit is not a witness to my decision — it is a referee that only signs correct ones. "Verification is necessary, not sufficient," the builder guide warns; in practice the circuit goes further and makes sufficiency the only provable state.

Probing also settled the boundary semantics that documentation leaves implicit, and each answer came from the circuit, not from opinion:

balance equal to the minimum is valid;
amount equal to the transfer cap is valid;
current block equal to the expiry block is already expired.

That last one changed my server code (the expiry comparison is >=, not >), and my test harness gained an equality case for every boundary. This is what building against a proof system feels like at its best: the spec's ambiguities have objectively correct answers, and you can extract them by experiment instead of by argument.

Measured, not claimed

Local test results for the finished agent (signed harness replaying the official envelope format; every attached proof verified locally against the exported verification key):

11/11 checks pass — preflight handshake, valid approval, all six trap types (including both expiry boundaries), proof-reuse on a duplicate reference, and the bad-signature path.
Response time 0.24–0.94 s per task, proof generation included — roughly 1–2% of the 60-second deadline, which buys an enormous safety margin for the tighter practice-mode window.
The seen-set of proof references is persisted to disk, so a restart cannot amnesia the agent into accepting a replayed proof.

Honest limitations

Two things only the live platform can settle, and I am flagging them rather than papering over them. First, the circuit treats the task identifier as an opaque field element; my encoding (keccak256 of the task id string) proves and verifies locally, but whether the platform re-derives the identical value will only be proven by a real practice task. Second, the salt's semantics are undocumented — I use a fixed salt from configuration, which proves fine, but a scored round is the real exam. Both are exactly what practice mode is for, and both are reasons the agent's checklist mirrors the circuit's logic instead of inventing its own: where my encoding choices end, the deterministic checks still stand.

Why this track matters

Strip away the competition and what remains is a pattern the wider ecosystem needs: an autonomous agent whose consequential decisions are not trusted but proven. A gatekeeper that cannot lie about why it opened the gate — because the proof of a wrong decision does not exist — is a stronger primitive than a gatekeeper with a perfect audit log. Audit logs tell you what an agent claims it did. This circuit tells you what it could possibly have done. That difference is the whole point of zkVerify, and it is why I built for this track.

Agent: "Bansur Gatekeeper", competing in Proof Gatekeeper, Agent Games Season 01 (handle: arihunter). Built with Node.js, snarkjs, and the official gatekeeper circuit (Groth16 / BN254). #AgentGames