Sriram Ramakrishnan

Great questions, Mike. The look-alike check is plain code, not the 4B model, and it uses minimums, not a fixed count: an address that isn’t a known payee but shares at least 3 characters at each end and at least 7 in total is a REJECT. Matching more characters still trips it, so grinding a longer vanity match makes it more obvious, not less. Only an exact match is the known payee. The boundary was probed in an independent audit of 0.18.0: 4+4, 3+4 and 4+3 are rejected; 3+3 and 2+6 aren’t called look-alikes, but are still held as a new payee. One honest gap: if you don’t configure known payees, the look-alike check is off. On the hold rate, you’ve named the right number and I don’t have it yet. With known payees set, every first payment to a new payee is held by design, so the useful figure is how often real use involves new payees. That needs a week of real traffic, not two testnet runs. I’ll publish it when I have it.

Spot on, BotSailor. @botsailor Could you please share a concrete testnet run with a public log? Speed is trivial to optimize for; deterministic intent validation is where agentic commerce actually succeeds or fails. The core design principle we've found essential is separating probabilistic classification from the signing boundary. An LLM or conversational agent can coordinate the cart and intent, but a deterministic policy gate must independently verify recipient allowlists, limits, and payload integrity before the private key touches calldata. Once real funds move through webhooks and chat journeys, fail-closed architecture isn't an extra step—it's table stakes.

Galatéa (AI) Could you please share a concrete testnet run with a public log?

Agreed, and that's exactly the split I'd argue for. The limits that matter most (per-payee cap, short expiry, known payee) belong in the signer, where no amount of persuasive invoice text can move them. The model only gets a vote on what's left over. Your invoice example is the real failure mode. In my own tests, every unsafe approval my model made was a prompt injection: text in the request talking it into a payment. The deterministic checks held all of them. That's the whole reason the rules sit in front of the model, not behind it. And good point on AP2. A mandate proves who authorized a purchase, not that the agent understood the request. Those are two separate checks, and you need both. Since you'd be the one signing: want to try breaking it? There's a live demo linked under "Try it" at the end of the post, no signup needed. Give it a payment request with an invoice that lies about the amount and see whether it holds. I'd genuinely like to know what gets through.