I Registered an AI Agent for zkVerify's Agent Games With a Signature — Then Hit the Wall Nobody Talks About

juseng111 — Sun, 15 Nov 2026 09:22:32 +0000

An honest build log from the Proof Gatekeeper track: SIWE registration with an agentic wallet, the seven traps, Groth16 proofs — and the one requirement that stopped everything before a single round.

#AgentGames

The tournament

Agent Games is zkVerify's Season 01 tournament for AI agents (21 October – 21 November 2026). Four tracks, 400,000 VFY in prizes, and every result verified on-chain with zero-knowledge proofs. I entered the Proof Gatekeeper track, where your agent acts as a payment guard: it receives a signed task, decides APPROVE or REJECT within 60 seconds, and proves its decision with a Groth16 zero-knowledge proof.

This is a record of what I actually did — registration, the design I settled on, and the wall I measured myself. I did not play a scored round. If any sentence below sounds like a round already ran, that is a misread.

Part 1: Registering without a browser wallet

Agent Games lets you sign in with an X account or a wallet. I had neither available in the way the site expects: my X login was already failing on its own, and my cloud browser has no wallet extension. The wallet path opens a browser extension to request the connection — and the page just sits there, waiting for a confirmation that can never come.

Underneath the "connect wallet" button is a standard called Sign-In With Ethereum — SIWE (EIP-4361). The flow is simple and worth understanding, because it is the whole identity model of the tournament:

The site hands you a short, one-time message containing a random value called a nonce.
Your wallet signs that message. Signing costs nothing — no transaction, no funds moved, no gas.
The site checks the signature. Only the real holder of that wallet could have produced it, so a valid signature proves control of the wallet.
The site issues a session. You are in.

No password exists anywhere in this flow. There is nothing to leak, phish, or reuse — the nonce makes each sign-in message unique and short-lived.

My agent used an existing EVM agentic wallet (a BSC wallet, 0x02fe…d6F9, created for airdrops) and ran exactly this flow programmatically: GET /api/auth/wallet/siwe/nonce, build the EIP-4361 message (agentgames.zkverify.io wants you to sign in with your Ethereum account: …, statement "Sign in to Agent Games with your wallet.", chain ID 1, 5-minute expiry), sign it with the wallet key, and POST the message and signature to the session callback. The session came back with registrationComplete: false — signed in, profile not yet created.

The profile step asked for a handle, country, bio, and optionally GitHub and a wallet address. I took the handle juseng111, country Indonesia, and completed registration through the site's own form action. The dashboard confirmed it: "PARTICIPANT CONTROL ROOM / @juseng111". The wallet address is optional at registration but required to claim VFY prizes — mine was already attached by the sign-in itself.

A signature is a claim. It says "whoever holds this key was here." It does not say the agent is good, honest, or even running. That is what the rest of the tournament is for — and it is why the next section matters more than this one.

Part 2: What the Gatekeeper actually has to do

Every task arrives as a signed JSON POST to the agent's endpoint. The platform signs it with a per-agent HMAC secret, and the first thing the agent must do is verify the x-agent-games-signature header against the raw request body — before parsing anything. A bad signature is a 401, no further work.

The task itself is a structured decision:

{
  "type": "agent-games.proof-gatekeeper.v1",
  "task_id": "gk_24_9d1",
  "mode": "competition",
  "input": {
    "registered_vk": "0x7d3a...f291",
    "proof_vk": "0xa4c1...b8ff",
    "minimum": "1000",
    "public_balance": "1460",
    "expiry_block": 19842201,
    "current_block": 19832000,
    "recipient": "0xDe42...9f01",
    "condition_recipient": "0xDe42...9f01",
    "amount": "500",
    "max_transfer": "1000",
    "proof_tx": "0xa4c1...8ff1"
  }
}

The agent answers with one deterministic decision and a reason code:

{ "decision": "REJECT", "reason_code": "VK_SUBSTITUTION", "proof_tx": "0xa4c1...8ff1" }

The decision is not a language-model judgement call. It is a fixed checklist over the task fields, and the tournament documents all seven outcomes before the competition opens. The test is whether your agent checks every field — not whether it can guess:

Outcome	Rule	Share
VALID_CONDITION	Everything checks out — approve	~50%
VK_SUBSTITUTION	Proof verifies, but its verification key is not the registered condition key — reject	~13%
THRESHOLD_MISMATCH	Proof and VK valid, but the public balance is below the required minimum — reject	~8%
PROOF_REUSED	The proof reference was already accepted in a previous task — reject	~11%
EXPIRED_CONDITION	Proof and condition valid, but the block-height expiry has passed — reject	~6%
RECIPIENT_MISMATCH	The recipient in the proof is not the address on the payment condition — reject	~6%
AMOUNT_OVERFLOW	The amount exceeds the single-transfer cap — reject	~6%

The scoring makes the asymmetry explicit: a correct decision is +12 either way, but a wrong APPROVE is −6 while a wrong REJECT is only −3. Approving a trap costs more than being too cautious. A timeout is −2, and a missing or invalid proof is −2 on top of losing the reliability bonus (+0 to +5, pro-rated by the share of your proofs that verified). Fail closed: any error, timeout, or uncertainty means REJECT. Never approve by default.

And the proof is the point. The agent must generate a Groth16 proof of its decision with snarkjs and the tournament's own gatekeeper circuit (BN254, Circom 2.x — gatekeeper.wasm and gatekeeper_final.zkey from the site's circuit downloads), then return the proof and its public signals in the signed response. The platform re-verifies every proof against its own registered verification key. You cannot swap in a friendlier key. The circuit asserts, inside the proof, that the decision bit equals the AND of the condition checks — so a wrong decision is unprovable, and a valid proof of a bad decision still loses on the decision score.

That is the sentence the builder guide puts in bold, and it is the most important one in the documentation: a proof can verify perfectly and still authorize the wrong action. Verification is necessary, not sufficient. Your agent must confirm what was proven, not only whether verification succeeded: the key matches the registered condition, the circuit and proof system are the ones the task expects, the public inputs prove the threshold, recipient, and action, the proof reference has not been used before, and the verification reached a finalized state before approval.

My design, settled before writing any agent code, was deliberately boring: a small Node.js endpoint that verifies the HMAC first, runs the checklist deterministically, keeps a persistent seen-set of proof references and task IDs (retried tasks return the identical cached response), generates the Groth16 proof locally, signs the response with the HMAC secret, and fails closed on everything else. No language model anywhere near the decision — the same input must always give the same output.

Part 3: The wall

Then the build stalled at the very first requirement — not the cryptography, but the address.

An agent has to live at a public HTTPS endpoint. No localhost, no private IP ranges, no custom ports. My build machine is a cloud VM with no public IP: its local address is 198.19.0.2 (CGNAT space), and the public IP the outside world sees belongs to an egress proxy, not to the VM. Nothing listens on it, and inbound connections are impossible.

So I tested the usual escape hatches, one by one, on 15 November 2026, and measured each failure:

cloudflared try tunnel: the binary downloaded fine, but requesting a tunnel failed — failed to request quick Tunnel: Post "https://api.trycloudflare.com/tunnel": tls: first record does not look like a TLS handshake. The Go-based client dials directly instead of using the proxy, and the gateway kills the connection.
localtunnel: hung for 60 seconds with no output at all, then killed by timeout. No tunnel URL, ever.
bore.pub: the binary download itself was refused by the URL filter, twice. And the transport was already proven impossible: a raw TCP connection to bore.pub:7835 was answered not by the bore server but by the gateway, with a policy message.

That policy message is the root cause, and it is worth quoting, because it names the exact switch:

muse: Other TCP connections is turned off for this assistant. To allow it, ask the user to open Muse settings -> Permissions -> Direct network protocols and switch other_tcp from Deny to Ask.

I confirmed it independently with a raw socket test: direct TCP to bore.pub:7835 and to server.localtunnel.me:443 both came back with the same policy reply. Only HTTPS through the egress proxy works; everything else is intercepted. Tailscale was checked and ruled out too — its client accepts inbound connections for nothing and hosts nothing. A Muse artifact/space is static client-side code and cannot receive the platform's POSTs. Named tunnels and ngrok need a signup and credentials I did not create without permission.

So the build stopped at step one, deliberately. No agent code was written, no agent was registered, no HMAC secret was issued, no money was spent. The account stays registered and the work stays real — but no round was played, and I will not pretend otherwise.

Part 4: What this actually teaches

The honest conclusion is not "the tournament is broken." It is that the tournament's hardest gate is not the cryptography. The circuit is public, the proving takes about three seconds, the checklist is seven lines of comparisons, and the scoring is published in advance. The hard gate is reachability: your agent must be a real, reachable, always-on network citizen, and a sandboxed build VM is not one.

That is, quietly, the whole thesis of the tournament. "Don't trust the agent. Verify it" is usually read as a statement about cryptography. But verification starts earlier: can the platform even reach you, can it tell your responses apart from a human's, can it check your uptime history on your public profile? A proof that nobody can fetch is not a proof. An agent that cannot be reached cannot be verified — and in this competition, it cannot play at all.

If I get the gate open — the permission switch above, a small VPS, or a tunnel account — the remaining work is bounded and known: build the endpoint, download the circuit, verify a proof locally with snarkjs groth16 verify, register the agent and store the one-time HMAC secret, pass the platform's signed preflight and at least one practice task, and be live before a round opens. Rounds run daily until 21 November, so the window is still open. If the gate stays closed, the fallback is this track — the Creator Track — where the work itself, documented honestly, is the entry.

Either way, the lesson survives the outcome: verifiable agents need verifiable infrastructure, and the first thing to verify is whether anyone can reach you at all.