Building a Proof Gatekeeper: an agent that cannot lie, because the math won't let it

Edwin — Sun, 15 Nov 2026 17:23:44 +0000

My build log for zkVerify Agent Games, Season 01 — Proof Gatekeeper track. #AgentGames

The assignment

In the Proof Gatekeeper event of zkVerify's Agent Games, your agent receives proof-backed payment requests and has to answer one question per request: APPROVE or REJECT?

Every request carries a zero-knowledge proof and a set of public claims: a verification key, a balance, a minimum threshold, an expiry block, a recipient, an amount, a transfer cap. Some requests are valid. The rest are traps — a substituted verification key, a reused proof, a balance below the threshold, an expired condition, a recipient mismatch, an amount over the cap.

Scoring is asymmetric on purpose: a correct answer earns points, a wrong reject costs a little, and a wrong approve costs double. That is exactly how a real gatekeeper should be incentivised — letting a bad payment through is the expensive mistake.

The part that makes this event different from a normal "build a classifier" challenge: your agent must attach a Groth16 proof of its own decision, generated with the event's official Circom circuit, and the platform re-verifies that proof against the registered verification key. You don't just claim you checked — you prove it, per task, in under 60 seconds.

The circuit is the referee

The most interesting discovery of this build: the circuit enforces honesty in both directions.

While testing, I tried to generate a proof for a dishonest approve — a request whose proof key had been substituted, answered APPROVE anyway. Witness generation itself failed, deep inside the circuit's constraints. The same happened for a dishonest reject of a fully valid request. The circuit's output is a binding hash over the decision and the task, and the constraints are only satisfied when the decision equals the honest evaluation of the inputs.

In other words: you cannot produce the proof for a lie. The agent's decision logic and the proof are not two separate steps that might drift apart — the proof only exists if the decision is the correct function of the inputs. One trap class falls out of this design for free: a reused proof can never be honestly approved or rejected with a proof, so the correct play there is a reject with no proof attached — which is precisely what the rules reward.

This is what proof verification infrastructure like zkVerify's is for: not trusting the agent, not trusting the operator — verifying the statement.

The checks, in order

My agent evaluates deterministically, cheapest and most decisive checks first:

VK_SUBSTITUTION — the proof's verification key differs from the registered key.
PROOF_REUSED — this proof reference was already submitted (kept in a persistent seen-set; the same task retried by the platform is idempotent, not "reuse").
THRESHOLD_MISMATCH — public balance below the required minimum.
EXPIRED_CONDITION — current block past the expiry block.
RECIPIENT_MISMATCH — recipient differs from the condition's recipient.
AMOUNT_OVERFLOW — amount above the maximum transfer.
Otherwise APPROVE.

Every field is encoded as a BN128 field element exactly as the circuit expects — verification-key hashes reduced modulo the field prime, non-numeric task IDs hashed into the field, a deterministic per-task salt. The public signals come out in the circuit's order: binding hash, registered VK hash, proof VK hash, minimum, balance, expiry, current block, recipient, condition recipient, amount, cap, decision, task ID.

Engineering notes

Transport: the platform signs every request with HMAC-SHA256 over the raw body; the agent verifies before parsing, and signs every response the same way. Task IDs double as idempotency keys.
Proving: snarkjs with the official gatekeeper.wasm + gatekeeper_final.zkey, running in a serverless function (Node on Vercel). A proof takes about a second — the 60-second task deadline is generous once the artifacts are bundled with the function.
State: the proof-reuse seen-set lives behind a small store interface — an Upstash REST set when configured, an in-process map otherwise (with a loud warning, because serverless instances forget).
Testing: 69 local checks before deploying — preflight handshake, tampered-body rejection (401), the valid approve, and all six traps, each with a locally verifying proof.

First contact with the platform

Registration generates a one-time HMAC secret, which goes into the deployment's environment — never into the repo. Then the moment of truth: a live practice dispatch from the platform itself.

The practice task was a VK-substitution trap. The agent answered REJECT / VK_SUBSTITUTION, the platform marked the attached proof VERIFIED, round-trip latency 893 ms. Everything I had only been able to test locally — envelope shape, signatures, field encodings, proof format — held up against the real verifier.

Practice proofs stay off-chain; competition tasks generate on-chain attestations by the platform, which is the zkVerify pattern end to end: prove off-chain, verify and attest on-chain.

What's next

Scored rounds run 16–20 November. The agent stays online around the clock; five rounds remain, 8 tasks each. After that: results, a post-mortem, and — win or lose — a public repo that anyone can audit:

Code: https://github.com/edwin1233/proof-gatekeeper-agent
Agent: "Edwin Gatekeeper", Proof Gatekeeper track, zkVerify Agent Games Season 01

May the most honest gatekeeper win.

DEV Community: Edwin