Coinbase x402 vs Google A2A: Duas Ordens de Pagamento Opostas para Pagamentos entre Agentes

Um desenvolvedor construindo um agente de pesquisa que distribui trabalho para três outros (pesquisa, resumidor, tradutor) precisava de pagamentos entre máquinas de frações de centavo. O mínimo de $0,30 do Stripe em uma chamada de $0,001 é 300x de custo adicional; o gás L1 on-chain é similar; assinaturas exigem pré-negociação humana. Eles encontraram x402, a implementação da Coinbase do HTTP 402 "Payment Required" — um facilitador sem estado para pagamentos de frações de centavo na Base, liquidando em ~2s por ~$0,0001 usando autorizações pré-assinadas EIP-3009 passadas como cabeçalhos.

A questão central: ordenamento de pagamento

Quando você tem verificar (rápido, off-chain), liquidar (lento, on-chain) e trabalho real (chamada LLM), três ordens são possíveis:

• A: verificar → executar → liquidar
• B: verificar → liquidar → executar
• C: verificar → reservar → executar → capturar (padrão de cartão de crédito — não possível com o design único do EIP-3009)

O middleware da Coinbase usa A; a extensão x402 do A2A do Google usa B. A diferença depende da duração do trabalho: o chamador da Coinbase é um endpoint de API rápido (sub-500ms), então a lacuna verificar-liquidar é insignificante. Para um agente chamando outros agentes, a janela se estende para segundos ou minutos — tempo suficiente para o pagador drenar sua carteira após verificar mas antes de liquidar, dando computação gratuita.

Liquidar primeiro vence para cargas de trabalho de agentes

O desenvolvedor escolheu B (verificar → liquidar → executar) porque o trabalho do agente custa dinheiro real ($0,30+ por chamada) e é lento. Com liquidar primeiro, um pagamento falho nunca executa o LLM. Eles testaram quatro cenários:

• Assinatura válida, carteira drenada antes da liquidação chegar → liquidação reverte, nenhum computação desperdiçada (perda $0).
• Duas requisições paralelas da mesma carteira com nonces diferentes, mesmo saldo → uma liquidação succeede, a outra falha na corrida da cadeia, nunca chega ao modelo.
• Cabeçalho de pagamento repetido → detectado na verificação de nonce antes de verificar, retorna 402.
• Timeout do facilitador em 10s mas a cadeia confirma em 25s → pagamento órfão (pagador debitado, tarefa falhou). Isso é uma propriedade de cadeia sob carga, não corrigível por ordenamento.

Um modo de falha do liquidar primeiro: pagamento chega, mas o trabalho falha (erro 500, bug). O provedor lida com metadados de nonce/auth persistidos e reembolsos manuais.

O fluxo completo é open source com testes e2e rodando todos os quatro cenários em um laptop. github.com/GetBindu/Bindu