Como agentes de IA pagam onchain: loop de 402 que limpa…

Agentes de IA pagam onchain com x402 tratando uma resposta HTTP 402 como uma cotação de preço, assinando uma autorização de stablecoin e repetindo a mesma solicitação com prova de pagamento. Um facilitador verifica a assinatura, bloqueia repetições, envia a liquidação onchain e o servidor libera o recurso uma vez que a confirmação corresponde ao SLA de finalização do serviço.

Principais Conclusões

• x402 incorpora pagamento no ciclo normal de solicitações HTTP: uma resposta 402 carrega termos estruturados, e o cliente repete com uma prova de pagamento assinada.
• Os papéis principais são o cliente (agente/aplicativo), o servidor de recursos (API) e um facilitador que verifica assinaturas, previne repetições e lida com a liquidação onchain.
• A maioria dos pagamentos de agentes usa liquidação de stablecoin, tipicamente USDC, porque o tempo de finalização é a experiência do usuário para comércio por solicitação.
• x402 é assinatura-primeiro: USDC/EURC comumente usam autorizações EIP-3009, enquanto outrosERC-20s usar Permit2, então o agente não transmite transações brutas por chamada.

Por que agentes de IA precisam de pagamentos x402

Software autônomo quebra as suposições incorporadas na monetização clássica de APIs.Chaves de API, fluxos OAuth, assinaturas e faturamento presumem que um humano pode criar uma conta, armazenar credenciais, rotacionar segredos e resolver falhas de cobrança. Um agente que deve operar sem supervisão não pode parar para abrir um painel, adicionar um cartão ou negociar um contrato. Essa incompatibilidade é o gargalo econômico por trás de muito da conversa sobre 'pagamentos de agentes em cripto'.

x402 ataca o problema na costura do protocolo que a web já reservou para isso: http 402. HTTP 402 “Pagamento Requerido” existe desde o início dos anos 1990, mas foi lançado sem uma maneira padrão de expressar preço, aceito ativos, e onde pagar. x402 preenche essa lacuna ao tornar o paywall legível por máquina e transformar o pagamento em um padrão de tentativa determinística em vez de um fluxo de checkout separado.

É por isso que x402 aparece na conversa sobre a economia de agentes explicada. Ele transforma “como os agentes de IA pagam” de um problema de integração de produto em um primitivo de solicitação-resposta. O 402 é a citação, a autorização assinada é o pedido, e o facilitador é o corretor de compensação que torna a liquidação um problema operacional de outra pessoa.

A tese é importante para os construtores: o SLA sendo vendido não é “pagamentos em blockchain.” É a latência de cumprimento previsível. Se o ponto final for interativo, o tempo de confirmação da cadeia se torna parte da especificação do produto, não um detalhe de implementação.

O loop de solicitação e pagamento x402

O mecanismo é um loop apertado que se assemelha mais a um aperto de mão em um local de negociação do que a uma página de checkout. O servidor de recursos não pede ao cliente para ir a outro lugar para pagar. Ele recusa a solicitação com termos estruturados, então espera uma nova tentativa que prove a intenção de pagamento.

O loop básico x402 funciona assim:

1. O cliente solicita um recurso pago. O agente de IA ou aplicativo envia uma solicitação HTTP normal para um ponto final da API. 2. O servidor de recursos retorna http 402 com termos. A resposta inclui instruções de pagamento estruturadas: preço, tokens aceitos, destinatário endereço, e a rede para liquidar. 3. O cliente constrói uma prova de pagamento.

O agente lê os termos e prepara um payload assinado que autoriza o movimento de tokens para aquele valor e destino exatos. 4. O cliente tenta novamente a mesma solicitação com um cabeçalho de pagamento. A nova tentativa anexa a autorização assinada como prova, transformando o pagamento em uma nova tentativa HTTP padrão em vez de um fluxo separado. 5. O servidor verifica e liquida, então retorna 200 OK.

A verificação é frequentemente delegada a um facilitador, que confirma a assinatura e submete a liquidação onchain antes que o servidor libere o recurso.

Dois detalhes são onde a maioria dos posts sobre “pagamentos x402 explicados” ficam confusos.

Primeiro, o padrão de nova tentativa é o produto. Ele torna o pagamento amigável à idempotência e automatizável, porque o cliente pode tratar “402 então tentar novamente” como uma máquina de estados determinística.

Segundo, os termos 402 não são uma credencial estática. Eles são instruções de pagamento por solicitação. Essa diferença é o motivo pelo qual x402 não é “apenas uma nova chave de API”, mesmo que a ergonomia do desenvolvedor possa parecer semelhante uma vez que o middleware esteja em vigor.

Facilitadores e liquidação baseada em assinatura

O facilitador é o desbloqueio operacional, não uma camada de conveniência. O fluxo da Eco define três papéis, e o facilitador é aquele que absorve as partes complicadas: verificação de assinatura, checagens de saldo, proteção contra replay, submissão onchain e confirmação de volta ao servidor de recursos.

É também onde a escolha de design central do x402 aparece na tela: movimento de token com assinatura primeiro. Para USDC e EURC, x402 comumente usa autorizações de transferência no estilo EIP-3009, onde o agente assina uma intenção e outra parte a submete onchain. Para outros ERC-20s, o fluxo usa Permit2. De qualquer forma, o agente não está criando e transmitindo uma transação bruta por solicitação. Ele está produzindo uma autorização assinada que pode ser liquidada pelo facilitador.

Isso importa para “pagamentos de máquina” porque muda o que o cliente deve manter e o que o servidor deve executar. O cliente precisa de uma carteira capaz de assinar o payload de autorização. O servidor não precisa executar nós ou gerenciar a tubulação de transações específicas da cadeia se puder chamar um facilitador.

Isso também reformula o risco como microestrutura. O facilitador está agindo como um corretor de compensação, então os construtores devem pensar sobre:

1. Replay e idempotência. O cliente tentará novamente após um 402, as redes podem ser lentas, e o facilitador deve rejeitar replays. Os manipuladores do servidor precisam de um “estado pago” que possa ser verificado de forma segura antes de servir. 2. Latência e finalidade. O facilitador pode responder rapidamente, mas o verdadeiro SLA é a confirmação da cadeia.

Se o serviço promete “segundos”, ele está implicitamente escolhendo trilhos onde a finalidade se encaixa. 3. Limites de confiança. Facilitadores públicos reduzem a fricção de integração, mas também se tornam uma dependência para verificação e submissão.

Notas Eco para facilitadores públicos da Coinbase (via CDP) estão disponíveis gratuitamente no Base eSolana, e também mencionaStellarsuporte com um relayer OpenZeppelin. Esse é um caminho rápido para o envio, mas ainda é uma dependência de liquidação que requer um pensamento explícito sobre modos de falha.

Cadeias, tokens e compromissos de desempenho

O tempo de finalização é a experiência do usuário para comércio por solicitação, que é o motivo pelo qual as implantações x402 se agrupam em trilhos rápidos. Eco lista x402 como ativo no Base, Solana, Stellar, Arbitrum, Polygon e Ethereum mainnet, e observa que Base e Solana são comumente usados devido às baixas taxas e rápida finalização.

Eco também fornece tempos de finalização indicativos que se mapeiam claramente às expectativas do produto: Solana a ~400ms, Base a ~2 segundos, Stellar a ~5 segundos e Ethereum L1 a ~12 segundos. Esses números não são triviais. Eles definem se um pagamento agente se sente como uma chamada de API ou como um checkout.

A liquidação de stablecoin é a outra metade da história de desempenho. Eco descreve stablecoins, principalmente USDC, como o token de liquidação dominante em x402. Isso é menos sobre ideologia e mais sobre manter a perna de pagamento sem adicionar risco de preço a um fluxo de trabalho automatizado. Se um agente está pagando por solicitação, a volatilidade transforma uma conta medida em um alvo em movimento.

O suporte à cadeia também precisa de uma linguagem cuidadosa. A lista "ativa" da Eco e a lista "suportes" do x402 V2 da Alchemy não são idênticas. A Alchemy diz que o x402 V2 foi lançado em dezembro de 2025 com suporte multi-chain e nomeia Base, Solana, Ethereum, Polygon, Starknet e Injective. A lista da Eco inclui Arbitrum e Stellar.

A maneira clara de ler isso é que a especificação pode ser multi-chain, mas o que é utilizável hoje depende de quais redes um determinado facilitador realmente liquida e quais tokens ele pode liquidar.

Para cargas de trabalho de alta frequência, o ponto da Alchemy sobre as sessões x402 V2 é a alavanca de desempenho chave. Sessões baseadas em carteira reduzem a sobrecarga de liquidação onchain por solicitação, mudando a experiência de "pagamento por chamada" para "acesso em streaming", onde a liquidação pode ser amortizada.

Usos do mundo real e padrões do ecossistema

O ponto forte do x402 é o pagamento máquina a máquina, onde o comprador é um software e o vendedor é um recurso HTTP. A Eco lista casos de uso ativos que correspondem ao que aparece em produção: acesso à API por solicitação, micropagamentos máquina a máquina por dados ou computação, paywalls de conteúdo, monetização de ferramentas MCP e acesso a marketplaces de dados.

A parte importante não é a lista de categorias. É a granularidade de preços. A liquidação por solicitação permite que um agente compare provedores dinamicamente, roteie com base no preço ou latência e pague sem chaves pré-provisionadas. Esse é o comportamento econômico que as pessoas querem dizer quando falam de pagamento agentivo.

O posicionamento no ecossistema é onde a confusão é cara. A Eco distingue o x402 do A2A e AP2 do Google e os trata como camadas complementares: A2A para comunicação e descoberta de agentes, AP2 para autorização e governança, e x402 para execução e liquidação. O erro é tratar o x402 como um concorrente do A2A ou AP2. Eles resolvem diferentes partes do fluxo de trabalho.

Em termos de cronograma, a Eco e a Alchemy colocam o lançamento do x402 em maio de 2025. A Allium relata a data de lançamento do whitepaper do x402 como 6 de maio de 2025, escrito pela Coinbase Developer Platform.

O cronograma de governança da fundação é menos claro: a Eco diz que a Coinbase e a Cloudflare lançaram a Fundação x402 em 2025, enquanto a Alchemy diz que a Coinbase contribuiu com o protocolo para a Linux Foundation e a Fundação x402 foi lançada em abril de 2026 com mais de 20 membros fundadores. Os construtores devem tratar isso como um detalhe de governança aberto, não como um bloqueador para entender o ciclo de pagamento.

Configuração prática e principais advertências

A integração é "leve" apenas se o loop de repetição for tratado como uma máquina de estados e não como um hack pontual. A Eco descreve um caminho típico do lado do servidor como middleware que intercepta solicitações não pagas, retorna 402 com os termos e verifica o pagamento na repetição, muitas vezes chamando um facilitador.

Uma lista de verificação pragmática de construção se parece com isto:

1. Defina o esquema de termos de pagamento que você emitirá no 402. Preço, token(s) aceito(s), endereço do destinatário e rede devem ser inequívocos. 2. Decida quem liquida o pagamento. Usar um facilitador público pode remover operações de nó e encanamento de cadeia, mas adiciona uma dependência que deve ser monitorada como qualquer outro processador de pagamentos. 3. Implemente idempotência em torno de "pago".

O cliente tentará novamente após um 402, e o servidor deve ser capaz de verificar o status do pagamento com segurança antes de atender. 4. Escolha trilhos que correspondam ao orçamento de latência do endpoint. Os tempos de finalização indicativos da Eco tornam óbvio por que Base e Solana dominam fluxos interativos. 5. Planeje para sessões se a carga de trabalho for de alta frequência.

As sessões baseadas em carteira x402 V2 da Alchemy existem porque a liquidação onchain por solicitação não escala de forma limpa para padrões de acesso em streaming.

As principais ressalvas dizem respeito principalmente às expectativas. A Alchemy afirma que o x402 processou mais de 100 milhões de pagamentos desde maio de 2025, mas esse número não é corroborado pelas outras fontes fornecidas. O suporte à cadeia também varia de acordo com o facilitador, então "suportado por especificação" e "ao vivo com um facilitador público" são declarações diferentes.

O arco da economia de agentes mais ampla explicado está se direcionando para o comércio de API que se assemelha ao fluxo de pedidos. O x402 é a peça que transforma o pagamento em uma nova tentativa determinística, com o facilitador atuando como a camada de compensação e a finalização da cadeia atuando como o SLA.

A Conclusão

Eu vi equipes tratarem o x402 como uma troca de credenciais e depois ficarem surpresas quando o primeiro incidente de produção não é "verificação de assinatura". É idempotência. O cliente tenta novamente após um 402, o facilitador está realizando verificações de repetição, e o servidor ainda precisa de uma verificação de estado pago limpa para não servir ou cobrar em dobro quando a latência aumenta.

O modelo mental que se sustenta é a microestrutura: o 402 é a cotação, a autorização assinada é o pedido, e o facilitador é o corretor de compensação. Uma vez que isso se encaixa, a finalização da cadeia deixa de ser um detalhe cripto e se torna o SLA que o ponto final está vendendo.

É por isso que a liquidação de stablecoin em trilhos de finalização rápida como Solana (~400ms) ou Base (~2s) continua aparecendo nos designs de pagamento agentes, enquanto caminhos de confirmação mais lentos forçam as equipes a voltarem para crédito offchain de qualquer maneira.

Fontes

• Eco
• Alchemy
• Allium