My AI Agent Moves Real Money. I Never Take Its Word for Anything.

I run an AI agent that operates a crypto wallet on BNB Chain. It mines tokens, claims free mints, and submits transactions on a schedule, including while I sleep. It is also — in the only sense that matters — untrusted. Not because it has misbehaved. Because "the agent said so" is not evidence. Every action it takes has to survive verification against the blockchain itself before anything gets signed. This is a field report on how that works in practice: the checks, the numbers, and the occasions where verification was the only thing between a good story and a bad transaction. It is also an argument for why a competition like the Agent Games, where an agent's work is judged by proofs instead of claims, is the honest format for machines that act in the world. First: every mining proof gets re-proven Two of the agent's standing jobs are mining protocols on BNB Chain, PEARL and AMNT. The pattern is the same for both. A solver program grinds through candidate numbers (nonces) off-chain until it finds one whose proof digest — a hash fingerprint computed from the wallet address and the nonce — falls at or below the contract's current difficulty target. Finding candidates is the easy half, and a solver's log file is full of them. None of those candidates is trusted. Before any batch is submitted, each one is re-verified against the live contract, three ways: Recompute the digest. The digest is recalculated from the wallet and nonce and must match what the solver claimed. A mismatch means the log is wrong, and the candidate is discarded. Check the live target. Targets move. The digest must still be at or below the target the contract reports now, not the target that existed when the solver found it. Check the used-proof registry. The contract records which proofs have already been spent. A proof that appears there is worthless, however good it looks. Only candidates that pass all three are batched. On 13 November 2026, that pipeline submitted 44 verified PEARL proofs and received 3,258.99 PEARL. AMNT runs on a daily cadence: 20 verified proofs a day, 50,000 AMNT a day. Each batch costs roughly 0.00005 BNB in gas — a small amount, but real money, and it is only ever spent on proofs that already passed verification. Second: the transaction itself gets audited Verifying the inputs is not enough, because a correct proof can still ride inside a wrong transaction. So before signing, the wallet builds a preview: a simulation of the exact call, showing precisely what the transaction would do. (A simulation is a dry run of a transaction against current chain state — it shows the outcome without committing anything.) The preview is validated against strict rules: Check What must be true Proof digest Recomputed digest matches the candidate Target Digest ≤ the live target at submission time Unused Proof absent from the contract's used registry Simulation The exact call succeeds in simulation Balance changes Exactly one: the expected reward, arriving at our wallet Allowances / authority No changes at all Gas Worst case under a hard cap, or we stop The balance-change rule does most of the work. If the preview shows anything other than exactly one inbound movement — the expected reward, to our wallet — there is no signature. No exceptions, no "probably fine," no resubmission of a transaction whose outcome is uncertain. A preview that deviates is a full stop, and the deviation gets investigated before anything else moves. Third: marketing lies, contracts don't Free-mint promotions arrive constantly in this ecosystem, and they are written to be believed quickly. Our rule is to read the contract, not the copy. One campaign promised a token bonus for minting a set of shares. Before spending anything, we read the verified contract source. There was no bonus mechanism in it at all — no function, no accounting, nothing that could ever pay it. (A small amount, 0.2 USDT, did arrive later, paid manually off-contract. Which proved the point rather than refuting it: the promise lived in someone's spreadsheet, not in code.) Another drop advertised itself as free. The contract showed the "free" reward only unlocked after roughly $52 of paid minting. We passed. The rule that emerged is simple enough to state in one line: chain truth outranks site copy, always. If a claim cannot be found in the contract or in a transaction, it does not exist. Fourth: even simulations lie — in one specific way A simulation is necessary. It is not sufficient, and we learned one precise way it can mislead. Some contracts price a fee by reading the gas price of the transaction itself; fees for Chainlink VRF randomness requests are the classic case. A standard simulation runs at a gas price of zero, so the fee computes to nearly nothing and the call passes cleanly. The real transaction, paying a real gas price, hit a fee the simulation never showed — and reverted. This happened twice, on two separate mints, before we isolated the cause. Two changes followed. The decisive simulation now runs with an explicit, realistic gas price, so fee logic sees the same numbers the real transaction will. And decisive reads are cross-checked on two independent RPC endpoints, because endpoints can disagree with each other within the same minute. A clean result from one source, under unrealistic conditions, is a hypothesis — not a green light. Fifth: a project that refuses to trust agents My favourite counterexample in this space is a collection called UNSOLVABLE. It does not ask agents to claim a mint. It makes them earn one. Inside short 15-minute windows, an agent must solve a three-stage challenge — a SAT problem, a graph-colouring problem, and a subset-sum problem — chained into a Wesolowski VDF. (A VDF, or verifiable delay function, is a computation that takes a prescribed amount of sequential time to perform, but produces a result anyone else can check quickly.) Solve everything in time and you still only enter a lottery for a five-minute on-chain permit to mint. The design principle is the point: the project verifies the computation, never the agent's claim. There is no step where anyone has to take the agent's word for anything. We have attempted ten windows so far. Their server has failed us ten times — connections dropped mid-solve, attempts expiring on their side — and our eligibility is still intact, because nothing was ever signed on a promise. Frustrating, certainly. Also exactly the right design. What zkVerify does with all of this Everything above is hand-rolled: RPC reads, recomputed hashes, preview rules, hard caps. It works, but it is artisanal. Every operator rebuilds the same discipline alone, well or badly. zkVerify is what this looks like as infrastructure. It is a Layer 1 blockchain built by Horizen Labs that does one job: verify zero-knowledge proofs, cheaply and at scale. Verifying a proof directly on a general-purpose chain is expensive, so instead a proof is submitted to zkVerify once, checked there by native verifiers, and the verified result is attested in a form that other chains and contracts can rely on without redoing the work. The claim "this was computed correctly" stops being a claim. It becomes a receipt anyone can inspect. The Agent Games apply the same idea to agents themselves. In the arena tracks, every decision and every move an agent makes must arrive with a Groth16 proof, and the proofs are checked against the platform's own registered verification keys. The agent cannot swap in a friendlier key. It cannot argue with the result. A valid proof of a bad decision still loses, and a good decision without a valid proof does not count — which is precisely how it should work. That is the standard I already hold my own agent to, stated as a protocol: don't tell me you did it correctly — hand me something I can check. An agent that moves money, trades, votes, or operates machinery will be believed exactly to the extent that its work product is verifiable. Competitions judged by proofs are how the field learns to build agents like that, and I would rather enter my agent's operating record into that argument than another thread of promises. I'll keep running mine the same way in the meantime: trust nothing, verify on-chain, sign last. AgentGames