I expected Coinbase and Google to agree on how agents pay each other. opened both repos and they do the exact opposite

Was building a research agent that farms work out to three others (search, summarizer, translator), all owned by different people, all running up their own LLM bills. Needed them to pay each other per call and realised I had nothing to actually do it with. Stripe was out immediately, \~30c minimum on a $0.001 call is 300x in fees. On-chain L1 gas, same story. Subscriptions need a human to set up a contract between every pair of agents ahead of time, which kills the whole point of agents finding and hiring each other on their own. None of the rails I knew do sub-cent machine-to-machine payments. Then I found x402, Coinbase's implementation of HTTP 402 "Payment Required", the status code that's been reserved and effectively unused in the spec for \~28 years. Stateless facilitator that never touches the funds, pre-signed auths via EIP-3009 on Base, settles in \~2s for \~$0.0001, and you pass the payment as a header so it composes down a call chain. Exactly what I needed. Started building and hit a question I thought was already solved: verify is fast, settle is slow, so what order do you run them in around the actual work? Three options: * A: verify → run → settle * B: verify → settle → run * C: verify → reserve → run → capture (the credit-card hold). EIP-3009 is one-shot with no reserve primitive, so C isn't on the table. I figured I'd just do whatever the reference implementations do. Opened Coinbase's middleware: it's A, settle after the work. Opened Google's A2A x402 extension expecting to confirm that: it's B, settle before. Two of the biggest teams in the space reading the same spec and landing on opposite answers. That's when it clicked that this wasn't a copy-paste decision. What reconciles them is how long the work takes. Coinbase's caller is usually a protected API endpoint that returns in under half a second, so the window between verify and settle is so tiny nothing can go wrong in it, A is fine. My caller is an agent running a model and maybe calling other agents, so that window stretches to the length of the whole task, seconds to minutes. Completely changes what can go wrong in the gap. So I went B. The reasoning is short: agent work costs real money (tokens, often $0.30+ a call), it's slow, and once the output exists it exists. Given that, settle-first is the only ordering where a failed payment doesn't gift the caller free compute. Then I sat down and tried to break it with four scenarios: * someone signs a valid payment, passes verify, then drains their wallet before settle lands → settle reverts, and because I settle first the LLM never ran, out $0. * two requests fired in parallel from the same wallet with different nonces, both pass verify against the same balance → one settles, the other loses the chain race and fails, but the loser never reached the model so nothing was wasted. * someone replays a captured payment header → caught at the nonce check before verify even runs, 402 back. * the ugly one: facilitator times out at 10s but the chain confirms the tx at 25s anyway. payer is debited, task still failed. settle-first does NOT save you here, it's an orphan payment you reconcile after the fact, a property of the chain under load and not something the framework can fix. settle-first also has its own failure I should be upfront about: payment lands fine but the work dies right after (provider 500, my bug) and now there's a paid job with no output. rare, but you handle it with persisted nonce/auth metadata and a manual refund instead of pretending it can't happen. Diagram of the full flow attached. It's open source and the e2e tests spin up a mock facilitator and an agent and run all four scenarios on a laptop. honestly still not sure B is the right default for everyone, so if you can see where it falls apart I'd like to hear it. 🌻 [github.com/GetBindu/Bindu](http://github.com/GetBindu/Bindu)