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.

​
A second program, and a token the store won’t take

The section above says this shows one program. On 26–27 August 2026 it stopped being one. A wallet held USDG. The espresso is priced in USDC, and let_me_buy pins classic SPL Token in its IDL, so a Token-2022 mint has no path through it at all. Not a preference, a structural fact about the program. Five transactions closed that gap end to end. The venue was derived, not chosen, and it proves itself. Given the pair of mints, the pool is found by matching the Whirlpool account discriminator and the two mint fields at offsets computed from the IDL, and then each candidate’s address is re-derived from its own configuration, mints and tick spacing. A pool that cannot reproduce its own address is dropped. The search proposes; the seed recipe disposes. That is what makes a wrong field offset refute itself instead of quietly returning a plausible wrong pool.
Four well-formed wrong answers were waiting on the first of these, and comparison caught each one, not inspection.The pool address: the surface first derived the fifth seed as a lookup on an adaptive fee tier, which makes the pool underivable. It is a caller-supplied tick spacing, and the wrong tier yields a real, valid, wrong pool.The tick arrays: seeded with an ASCII decimal string, which the surface encoded as a 32-bit integer because that is how the IDL declares the argument. An argument’s declared type does not determine its seed encoding.The direction: b→a walks ticks up and a→b walks down. Only the array holding the current tick is shared between them.The USDG account: derived under Token-2022, where our helper had been defaulting to classic SPL, including in the agent-facing tool. One instruction, two different token programs.
And the trap that cost three transactions. The wallet first funded with USDG was the store’s own authority, so the buyer’s token account and the store’s are one address, and the payment would credit the account it debits. The plan check refuses that, correctly. But by then the swaps funding that wallet had been paid for. The lesson is about ordering: a structural refusal has to run before a route is quoted, or you pay for a route to a place you were never able to reach. The check now runs first. What these five did not show at the time. Every one was settled by a script run by hand, and nothing shipped could yet look inside a wallet to answer “buy an espresso, I only have USDG” with the conversion instead of the storefront. The section below is what changed.
On the predictions in this table. The charged figures are read back from the chain and re-checked by scripts/mainnet_ledger.py --verify. The predictions were recorded in the running session’s notes at the time and the receipt output was not kept, so they are transcribed rather than captured: accurate against the chain, but a weaker record than the earlier runs, where the prediction was written down before the transaction settled. docs/mainnet-swap-chain.md in the engine repo states that distinction in full. We would rather publish the difference than average it away.

​
Since then: the hosted path, signed headless

By 2026-09-01 the same loop ran through the hosted MCP surface (mcp.geckovision.tech/orquestra/mcp) with no script and no shell. The surface gained plan_payment and plan_swap, so “I only have USDG” is now answered with a checked route. prepare_purchase and prepare_instruction return unsigned bytes, a receipt, and a binding at exact strength. A hosted signer signed them headless. The three transactions below are the last three rows of the engine repo’s ledger (docs/mainnet-ledger.jsonl), which holds 50 landed mainnet transactions in total. Two honest notes. The ledger records no compute prediction for #25 and #26, so they count as landed with an exact binding, not as exact predictions. And #24’s first send expired unlanded on the public RPC; the identical signed bytes, rebroadcast every ~1.5 seconds, landed in seconds. That measurement is why submit_transaction exists: it verifies the signed bytes against the binding, sends, and rebroadcasts the same bytes until they confirm or the blockhash budget is spent. Same bytes, same signature, so the loop cannot double-spend.

​
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 signed nothing. It never does. What it relayed to the chain was signed bytes that had been re-checked against the receipt’s binding first, and that is the only thing it ever relays.

​
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. To run the hosted loop instead, follow agents.md.

How the receipt works

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

The program surface

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