Skip to main content
Every other page here ends at a simulation. This one ends on chain — and the point is simple enough to say in one line: before the money moved, Gecko said exactly what would happen, and that is exactly what happened. On 2026-08-06 an agentic wallet bought a bottle of water at a bar that takes crypto — 0.1 USDC, Solana mainnet, a real store, a real product. Before it was signed, Gecko planned the call, simulated it against live mainnet, and bound the receipt to the exact message. Then a wallet signed it and it landed.

​
Check it yourself

Open this transaction on Solscan ↗
Nothing on this page requires taking our word for it. Open the link, or ask a node directly:

​
Then we did it ten more times

One exact match can be luck. On 7 August 2026 the same agent bought ten more bottles, 0.1 USDC each, each one planned and simulated against live mainnet before it was signed. Every receipt predicted 36,399 compute units. The chain charged 36,399. Ten times out of ten. The books balance to the unit: 1.0 USDC spent, and exactly 50,000 lamports of fees — ten transactions at Solana’s 5,000-lamport base fee.
36,399, not 36,508. The first purchase wrote a record into the store’s account, so the program does slightly different work now. Both numbers are correct for the state they were measured against — which is the whole point, and why a receipt is taken at the moment you sign rather than the day before.

​
Then the agent did it without us

Every transaction above was signed by a key on a laptop. On 12 August 2026 that stopped being true. The key moved into a hardware enclave and never came back. Gecko asked a Privy server wallet to sign; the private key has never existed on the machine that planned the transaction, and nothing in Gecko can acquire one. The whole path — comprehend, plan, simulate, bind, check the spend policy, sign, broadcast — ran in one call, with no human in the loop. Sixteen transactions. Sixteen exact predictions.
#14 is the interesting one: 22,527 CU, not 36,399 — and predicted exactly anyway. It bought from a different storefront (geckocoffee), one that was not on any wired list. The agent derived the store’s address from its name, read the store’s own account off the chain, decoded the merchant and the menu out of it — Espresso, 0.1 USDC — and walked the same verify-then-sign path. Different store, different account state, different work, different number. The receipt predicted that number to the unit, which is the property this page exists to demonstrate: the prediction tracks the state, not a memorised constant.
The first attempt was refused, and by the right party. The enclave’s own policy engine rejected it: policy_violation. Wallet policies there are deny-by-default per method, and the policy attached to that wallet only described a method we deliberately do not use — the one that signs and broadcasts in a single step. Gecko asks for a signature and submits the bytes itself, so that the signed message can be re-checked against the receipt before anything reaches the chain. A vendor that broadcasts for you turns that check into a post-mortem.Fixing it meant adding a rule for the method we do use, restricted to the exact programs this purchase touches. Which means the program allowlist now exists on both sides: in Gecko, and inside the enclave, where we cannot switch it off either.
What this shows: one instruction, predicted exactly, sixteen times across three days, two storefronts and several account states — the last five with no key on the planning machine. What it does not show: breadth. This is one program. The program surface is where that claim is made and measured separately. And one thing it does not show that we would rather say out loud: three of the four spending caps in that run are real controls, but the rolling velocity counter is a file the same process can write. A compromised agent could reset its own budget. Moving those caps into the enclave — where the program allowlist already lives — is the next piece of work, not a finished one.

​
Three things had to agree

Gecko answered will this work — simulated, bound, PASS. The wallet answered who signs it. The wallet’s policy answered are you allowed to spend this — a single- transaction limit, enforced independently. Those are different guarantees, and none substitutes for another. A policy that approves your spending limit cannot tell you the transaction reverts; a simulation that says it lands cannot tell you whether you were allowed to make it. Gecko held no key and broadcast nothing. It never does.

​
The part that didn’t go to plan

The video re-runs the pre-flight live, and the numbers don’t match:
109 units apart — because this very purchase wrote a record into the store’s receipts account, so the program does slightly different work now. That’s not a defect, and hiding it would have cost the more useful lesson:
A receipt is true for the state it was taken against. Take it at the moment you sign — not the day before. It’s the same reason a receipt’s strongest binding expires with its blockhash, about a minute.
For the record, the pre-flight run immediately before the send did predict 36,508 exactly. We don’t show that on camera, because it can’t be re-derived now that the state has moved — and a demo that can’t reproduce its own claim shouldn’t make it.

​
Do it yourself

The same pre-flight runs against any wired program:
You get the call it chose, what it rejected, every account with where it came from, and a receipt — before anything is signed or spent.

How the receipt works

Status, compute units, categorical failure class — and what it does not claim.

The program surface

Seed recovery, provenance per account, and the gaps we flag instead of guessing.