A armadilha da confiança dos protocolos abertos: por que o x402 precisa de uma camada de responsabilidade centralizada?

O protocolo de pagamento x402 revelou 31 novas vulnerabilidades, com 99% das transações enfrentando risco de roubo de ativos.

Escrito por: @Jun__Yoo

Compilado por: AididiaoJP, Foresight News

Akiba, da CryptoSlate (@akibablade), publicou recentemente um artigo intitulado "31 novas vulnerabilidades fazem 99% dos pagamentos criptográficos x402 enfrentarem risco de roubo de ativos e compras gratuitas".

Este artigo é baseado em um trabalho intitulado "Quando o HTTP 402 encontra a blockchain: os riscos do emergente pagamento x402". Este trabalho foi aceito e será apresentado na conferência USENIX Security 2026.

O artigo foca em como o x402 delega a verificação de provas de pagamento e a liquidação on-chain a facilitadores de terceiros. Este design centraliza a lógica de confiança e verificação em uma infraestrutura de pagamento compartilhada por vários comerciantes independentes. Se um facilitador apresentar uma vulnerabilidade, isso pode afetar uma grande quantidade de serviços.

Os pesquisadores também definiram oito regras de segurança que os facilitadores devem seguir. A violação dessas regras pode resultar em quatro tipos de ataques: compras gratuitas, roubo de ativos, negação de serviço e abuso de Gas. Eles avaliaram 15 facilitadores principais e descobriram 49 violações de regras e 31 vulnerabilidades desconhecidas anteriormente. Os resultados foram divulgados em particular às partes operacionais relevantes. Alguns problemas já foram corrigidos, enquanto o trabalho de correção dos demais está em andamento.

A razão pela qual esta pesquisa pôde ser realizada é que o x402 foi desenvolvido como um protocolo aberto desde o início. As especificações do protocolo e o SDK de referência são públicos, permitindo que os pesquisadores deduzam as regras de segurança do processo de pagamento. Eles usaram um SDK de código aberto e comerciantes de teste que montaram para completar a pesquisa.

O código aberto não elimina vulnerabilidades, mas oferece um caminho para que falhas descobertas externamente possam ser convertidas em padrões de segurança compartilhados. O protocolo x402 foi transferido para a Linux Foundation em 2 de abril, e a x402 Foundation começou oficialmente suas operações em 14 de julho, com 40 membros. Isso fornece um fórum oficial para discutir os resultados encontrados em nível de especificação e implementação de referência, em vez de se limitar a patches de um único fornecedor.

Os pesquisadores também lançaram uma versão pública do x402scope, que removeu códigos de exploração sensíveis. Eles estão discutindo com a Coinbase e outros participantes principais do ecossistema como integrar suas verificações de regras nos processos de validação antes do desenvolvimento e implantação.

A discussão sobre a maturidade do protocolo termina aqui. Quero levantar uma questão mais fundamental a partir dessas descobertas.

Em vez de centralizar o x402 em si, um protocolo aberto precisa de uma camada de responsabilidade centralizada para impor padrões de verificação e arcar com os custos e perdas de liquidação decorrentes de eventos de segurança?

Centralização não é automaticamente igual a segurança. Mas no campo dos pagamentos, a parte que exerce poder também deve arcar com o custo do fracasso.

Vamos olhar como o x402 realmente funciona. Qualquer um pode operar um servidor ou se tornar um facilitador. Mas o sistema não é completamente sem confiança. O artigo também define o facilitador como "um intermediário que assume a confiança". Uma vez que a verificação e a liquidação são delegadas, os usuários devem confiar em uma medida considerável no facilitador.

O problema é que a confiança está centralizada, mas o protocolo não exige capital, mecanismos de responsabilidade ou certeza de pagamento correspondentes. Essa lacuna se reflete em três partes do design.

Primeiro, a verificação parece mais uma previsão de "a liquidação ainda é viável neste momento", em vez de uma autorização de cartão de crédito. Ela verifica assinaturas, saldos, nonce e tempo de expiração, mas não bloqueia fundos nem consome nonce.

Em segundo lugar, a separação entre verificação → lógica de negócios → liquidação visa proteger consumidores e comerciantes. O protocolo não tem um mecanismo para vincular verificação e liquidação por meio de estado compartilhado. Se um comerciante agir com base nos resultados de verificação do facilitador e a liquidação subsequente falhar, o comerciante arcará com toda a perda.

Terceiro, muitos facilitadores patrocinam os custos de liquidação on-chain. Um atacante pode manipular o caminho de execução, fazendo com que o facilitador pague as taxas de Gas resultantes. No Solana, um atacante pode até induzir o facilitador a pagar aluguel para uma conta controlada pelo atacante.

Os pagamentos com cartão de crédito também separam autorização e cobrança. A diferença é que o emissor do cartão reserva parte do limite de crédito ou fundos do portador do cartão durante a autorização. As regras da rede, em seguida, oferecem ao comerciante um certo grau de certeza de pagamento. Se algo der errado, ainda há a possibilidade de cancelamento da autorização, chargeback, sanções ao comerciante e procedimentos de resolução de disputas.

O x402 não tem um emissor de cartão para bloquear fundos e garantir pagamentos. Os servidores, portanto, verificam a viabilidade do pagamento, executam a lógica de negócios e, em seguida, chamam a liquidação. O problema é que as duas extremidades não compartilham estado. Após a verificação, o saldo, nonce ou validade podem mudar. Se o servidor executar uma operação irreversível antes da liquidação, o comerciante pode sofrer perdas. Se o facilitador enviar uma transação manipulada, ele pode perder Gas ou ativos que controla.

As redes de cartões assumem esse custo de confiança por meio de capital e equipes de gerenciamento de risco do emissor, e depois recuperam isso por meio de taxas. O x402 removeu esse papel, mas não removeu o custo.

Portanto, o caminho real precisa de uma camada de responsabilidade construída sobre o protocolo aberto?

Aqui, a centralização não significa entregar todo o protocolo x402 a um único operador. Cada rota de pagamento deve ter um responsável claramente definido. Vários operadores ainda podem competir sob o mesmo padrão aberto, e os usuários podem mudar de facilitador. Essa estrutura centraliza a responsabilidade operacional, enquanto mantém a abertura do protocolo e a competição entre fornecedores.

O Monetization Gateway da Cloudflare é um exemplo possível. Ele mantém o formato de pagamento programável do x402, enquanto lida com políticas de pagamento, verificação e controle de acesso em uma única camada de controle. Outro caminho é usar facilitadores especializados que oferecem acordos de nível de serviço, limites de Gas, revalidação antes da liquidação e resposta a eventos.

O ERC-8004 e os sistemas de reputação parecem oferecer alternativas. Mas a reputação é apenas um sinal adicional para avaliar riscos, não reserva fundos nem fornece garantias de pagamento. Acredito que a reputação sozinha não pode preencher a lacuna de responsabilidade.

Essa perspectiva também exige uma reavaliação do papel e da estrutura da camada de descoberta. Essa camada pode ir além de simplesmente listar serviços disponíveis, tornando-se uma camada de confiança e roteamento, filtrando quais recursos e facilitadores atendem aos padrões de segurança estabelecidos. Se garantias de pagamento forem necessárias, ela pode distinguir claramente entre operadores centralizados que oferecem garantias e rotas de pagamento. Sob essa perspectiva, dois jogadores-chave merecem atenção:

A estratégia de integração da CDP (@CoinbaseDev) combina a Agentic Wallet, CDP Facilitator e Bazaar, oferecendo funções de carteira, pagamento, conformidade e descoberta em uma única pilha tecnológica.

A estratégia de integração da Orthogonal (@orthogonal_sh) unifica descoberta de serviços, pools de chaves API, padronização de respostas e faturamento sob uma única conta, um saldo e uma fatura. Ela suporta créditos, x402 e MPP. Isso coloca a complexidade de gerenciar vários fornecedores e métodos de pagamento sob um gateway central.

Essas estratégias ainda não falam sobre garantias de pagamento ou absorção de perdas. Mas elas colocam funções fragmentadas de carteira, verificação, faturamento e descoberta sob um único operador, fornecendo uma base para uma camada de responsabilidade centralizada.

Se a camada de responsabilidade centralizada se tornar comum, a própria estrutura de pagamento também pode mudar. Um modelo possível é substituir verificação → lógica de negócios → liquidação por verificação → liquidação → lógica de negócios.

A ordem atual protege os consumidores, desde que a liquidação seja irreversível. Uma vez que o operador assuma a responsabilidade por reembolsos e resolução de disputas, essa suposição mudará. A liquidação pode ser confirmada primeiro, eliminando o risco de não pagamento para o comerciante. Se a execução subsequente falhar, o operador pode reembolsar o consumidor. O operador, então, deve arcar com a necessidade de liquidez e a obrigação de liquidação antes da liquidação final, tornando sua estrutura de capital e responsabilidade ainda mais importante.

Esse modelo não segue o processo de liquidação por transação atual do x402. O x402 continuará a atuar como uma interface aberta para comunicar termos de pagamento e dados de autorização. O operador agregará o fluxo real de fundos e concluirá a liquidação final on-chain. O registro de cada pagamento será mantido no livro interno do operador, enquanto a blockchain registrará a liquidação final agregada. Como o livro interno é reversível, essa estrutura reduz o problema de pagamentos irreversíveis. O operador também pode lidar com reembolsos e disputas como um emissor de cartão.

Alguns podem perguntar:

Isso não é apenas tratar a blockchain como um banco de dados de pagamento compartilhado?

Sim.

Mais precisamente, a blockchain se tornará um livro contábil de liquidação compartilhada que registra os saldos finais entre os operadores. Cada pagamento individual permanece fora da cadeia. Pelo menos neste mercado, desempenhar esse papel de forma confiável pode ser suficiente. O sistema ainda pode aproveitar os baixos custos de liquidação e as vantagens das moedas programáveis.

Este conteúdo é fornecido apenas para fins informativos gerais e não constitui aconselhamento financeiro, de investimento, jurídico ou tributário. Quaisquer eventos, recompensas, promoções online ou informações relacionadas mencionadas neste documento não devem ser consideradas uma recomendação, solicitação ou convite para comprar, vender, negociar ou realizar qualquer outra transação com criptoativos. Criptoativos são altamente voláteis e podem resultar em perdas. A disponibilidade dos serviços, produtos e eventos relacionados da WEEX pode variar conforme a região. É de sua responsabilidade garantir que sua participação esteja em conformidade com as leis e regulamentações locais aplicáveis.