A Coinbase reclassifica o x402 para «neutro», enquanto a Stripe continua a apostar em ambas as opções fora do MPP

Autor: Charlie, Diretor da OSL Americas, Sócio da Generative Ventures. Ex-vice-presidente da Strike, uma empresa unicórnio do setor das criptomoedas (envolvido na lei do Bitcoin de El Salvador e responsável pela Bitcoin Lightning Network e pelo negócio de pagamentos com stablecoins na América Latina), analista macroeconómico e cambial no fundo de 1 bilião de dólares Franklin Templeton e um dos primeiros membros da gigante global de pagamentos Adyen.

O artigo reflete as opiniões pessoais do autor e não representa as posições das empresas mencionadas.

Ultimamente, cada vez mais amigos têm-se interessado pelo comércio agênico, mas os diversos protocolos e intervenientes têm-se tornado cada vez mais confusos.

Especialmente na semana passada, enquanto todos estavam ocupados a tentar compreender o MPP da Stripe / Tempo, a Stripe aderiu inesperadamente à Fundação x402 da sua concorrente, a Coinbase.

Além disso, a Cloudflare agora é compatível com ambos os sistemas. O Google também está envolvido, mas tem o seu próprio AP2 e UCP.

A Visa e a Mastercard também aderiram, mas é evidente que não o fizeram para apoiar as stablecoins.

A Linux Foundation define publicamente o x402 como um «ponto de partida» neutro e co-gerido pelo setor, enquanto a Cloudflare incluiu explicitamente tanto o x402 como o MPP no seu próprio SDK de Agentes, e a Stripe também declarou publicamente que suporta tanto o MPP como o x402.

Quem está a competir com quem e quem está a sobrepor-se a quem?

No entanto, quanto mais analiso a situação nos últimos dias, mais sinto que este «caos» não se deve a uma falta de orientação do mercado, mas sim ao facto de o mercado já estar muito claro. Como já referi anteriormente no x402, é possível que tenhamos interpretado mal a sua intenção original: desde o início, esta questão não seria unificada de uma só vez por um único protocolo.

É uma situação comum na infraestrutura da Internet: diferentes camadas estão a desenvolver-se em simultâneo, diferentes empresas apostam em camadas diferentes e, em última análise, será a interoperabilidade que fará com que tudo funcione.

A verdadeira questão estratégica reside em saber quem irá definir a camada de controlo padrão para o acesso pago às máquinas na web agênica; e os principais intervenientes estão claramente a adotar uma estratégia de multi-homing, uma vez que todos continuam a apostar em qual será o verdadeiro ponto de estrangulamento — a autorização, a distribuição ou a liquidação.

1. Por que é que a Coinbase cedeu a x402 Foundation ao Linux?

Se o x402 fosse apenas um protocolo da Coinbase, seria difícil tornar-se a opção padrão do setor.

Esta não é uma afirmação politicamente correta, mas sim uma lógica de normalização realista.

A declaração da Linux Foundation desta vez é muito clara; salienta a neutralidade dos prestadores de serviços, a governação comunitária e a infraestrutura partilhada, em vez de referir que «uma determinada empresa lançou uma nova funcionalidade do produto».

Mais importante ainda, a página da Fundação x402 indica atualmente que o projeto se encontra na fase de constituição e que o mecanismo de governação e o conselho de administração ainda estão a ser criados.

Por outras palavras, esta iniciativa não visa, em primeiro lugar, anunciar que «o produto está maduro», mas sim que «pretendemos proporcionar a este protocolo um espaço neutro».

A implicação subjacente é bastante simples.

Se o x402 continuar a apresentar as características de uma funcionalidade do Coinbase (como o atual Base), os fornecedores de serviços na nuvem, as empresas de pagamentos, as organizações de cartões e os operadores de plataformas, mesmo que estejam tecnicamente dispostos a adotá-lo, hesitarão por razões políticas.

Ninguém quer entregar a futura camada de acesso pago a uma única plataforma. A decisão de colocá-lo sob a alçada da Linux Foundation não se deve ao facto de a Coinbase não querer controlá-lo; pelo contrário, é precisamente porque pretende que o x402 seja amplamente adotado que deve, em primeiro lugar, eliminar o estigma de que «este é o protocolo da Coinbase».

Este ponto é, na verdade, muito importante, porque muitas pessoas encaram ações como as da fundação apenas como manobras de relações públicas ou gestos de código aberto.

Mas, na guerra dos protocolos, a governança faz parte do produto.

Especialmente quando uma norma ainda se encontra numa fase inicial e carece de efeitos de rede absolutos, a chamada «neutralidade e fiabilidade» não é menos importante do que a elegância técnica.

Por outro lado, se o x402 vier a tornar-se, de facto, uma espécie de padrão de referência para o acesso pago nativo do HTTP no futuro, provavelmente não será porque o seu código é o mais elegante, mas porque conseguiu reduzir os custos políticos mais cedo do que outras soluções.

Por outras palavras, a governação, neste contexto, não desempenha um papel secundário; a própria governação é um motor de crescimento.

2. O que é que a dupla estratégia da Stripe está realmente a fazer?

O protagonista a seguir de perto desta vez é, sem dúvida, a Stripe, uma vez que as suas ações são as mais confusas.

Por um lado, lançou o MPP com grande alarde a 18 de março, apresentando-o como um padrão aberto para pagamentos automáticos.

Por outro lado, é um dos contribuintes fundadores da Fundação x402 e a sua própria documentação também suporta pagamentos por máquina x402.

A documentação da Cloudflare é ainda mais direta, afirmando explicitamente que o MPP é compatível com versões anteriores do processo de pagamento central do x402 e que os clientes MPP podem utilizar diretamente os serviços x402 existentes.

Se analisado exclusivamente sob a perspetiva da «competição de protocolos», a Stripe parece estar a adotar uma estratégia dupla.

Mas, se alargar um pouco a sua perspetiva, esta abordagem é, na verdade, a que faz mais sentido do ponto de vista comercial.

Porque o que a Stripe realmente quer proteger não é apenas o próprio protocolo 402.

O que realmente pretende proteger são as camadas acima do processo de transação: credenciais, conformidade, risco, relatórios, impostos, reembolsos e integração com os comerciantes.

A Stripe não parece acreditar plenamente em nenhum protocolo específico; pelo contrário, parece estar a garantir que, independentemente do padrão de handshake que venha a prevalecer, a Stripe continue a ser a camada de abstração padrão para os pagamentos dos agentes.

Apoiar o x402 significa garantir a participação no ecossistema aberto; impulsionar o MPP significa ajudar a definir a semântica subjacente; e promover ainda mais o ACP e os tokens de pagamento partilhados significa salvaguardar a camada de valor mais abrangente dos fluxos de trabalho e das credenciais de pagamento.

Assim, o aspeto mais «estranho» do Stripe desta vez é, na verdade, o seu aspeto mais sincero.

Não se pretende que, no futuro, tudo se reduza rapidamente a um único protocolo. A situação está a mostrar que, pelo menos nesta fase, ninguém deve apostar apenas num dos lados.

3. Na verdade, trata-se de uma história sobre infraestruturas B2B

Tenho cada vez mais a sensação de que muitos meios de comunicação têm direcionado indevidamente a atenção para esta questão.

Quando se trata de comissões dos agentes, o exemplo mais fácil de imaginar é o comércio a retalho: A IA ajuda-o a reservar voos, reservar hotéis, fazer encomendas e concluir o processo de pagamento.

Mas se analisarmos os cenários que foram efetivamente implementados publicamente e que apresentam realmente características de infraestrutura, o primeiro a ganhar força não é o processo de checkout no retalho, mas sim o acesso pago B2B, mais prosaico e concreto: APIs pagas, dados pagos, ferramentas pagas, sessões de navegador pagas e fluxos de trabalho de agentes pagos.

A Cloudflare oferece agora suporte oficial à cobrança por conteúdo HTTP, APIs e ferramentas MCP utilizando x402 e MPP.

A via de adoção mais sólida para o x402 reside nas APIs e ferramentas pagas entre programadores, porque, neste contexto, o modelo «sem conta + pagamento por pedido» não é apenas um artifício, mas uma realidade operacional genuína.

As mudanças subjacentes a isto são bastante significativas.

No passado, cobrar pelo uso de uma API normalmente exigia passar por todo um conjunto de processos «fáceis de gerir»: abrir uma conta, associar os dados de faturação, emitir chaves de API, definir limites, fazer a reconciliação e, por fim, gerir as autorizações de pagamento.

Para os humanos, isto já é bastante irritante; para os agentes, é ainda mais incómodo.

O aspeto mais interessante do x402 não é o facto de envolver mais criptografia ou mais IA, mas sim o facto de tentar reintroduzir o «acesso pago» no próprio HTTP, permitindo que o controlo de acesso e a negociação de pagamentos ocorram como uma solicitação-resposta normal.

O servidor devolve um código 402, indicando o custo desta solicitação; o cliente efetua o pagamento e, em seguida, repete a mesma solicitação com as credenciais de pagamento.

Se analisarmos este modelo do ponto de vista do software B2B e do acesso máquina a máquina, o seu funcionamento é muito mais fluido do que quando analisado do ponto de vista do retalho.

Além disso, quanto mais se analisa o setor B2B, mais evidentes se tornam as vantagens do x402 e menos graves são as suas limitações.

Porque no comércio de retalho, os reembolsos, os estornos, o comerciante registado, a proteção do consumidor e a atribuição de responsabilidade são questões complexas; mas nas chamadas de API e ferramentas B2B, a importância destas questões diminui significativamente.

Por outro lado, «sem conta, pagamento por chamada, resultados imediatos e pronto» é uma exigência real.

O retalho é, sem dúvida, mais vasto, mais dinâmico e mais capaz de chamar a atenção; mas os cenários que definem verdadeiramente a forma do protocolo não são, muitas vezes, os mais dinâmicos, mas sim aqueles que revelam, em primeiro lugar, as necessidades reais.

No que diz respeito à atual onda de pagamentos a agentes, esse cenário provavelmente não se refere ao carrinho de compras, mas sim ao número crescente de acessos pagos entre software, agentes e fluxos de trabalho.

4. A evolução do setor confirma a minha opinião anterior sobre a interoperabilidade

A ideia central do meu último artigo foi a interoperabilidade.

Na altura, essa opinião parecia sugerir, de certa forma, que «deveria ser estruturado desta forma».

Agora, isto assemelha-se cada vez mais a uma limitação da realidade, uma vez que o mercado livre já está a dar sinais claros da sua reação.

A Cloudflare não tomou partido, mas suporta diretamente tanto o x402 como o MPP, ao mesmo tempo que estabelece claramente mapeamentos de compatibilidade.

A Google está a participar no x402, ao mesmo tempo que continua a promover o AP2 e o UCP.

A Visa e a Mastercard também não revelaram as suas estratégias como se houvesse um único vencedor; em vez disso, ambas estão a aderir à x402, ao mesmo tempo que continuam a apostar fortemente nos tokens de agente, na verificação de identidade, na validação de instruções e nos sinais de litígio.

As apostas multilaterais feitas pelos gigantes são decisões racionais, não hipocrisia comercial.

Por que é que isto acontece? Porque esses protocolos nem sequer estão na mesma camada.

Pelo menos até agora, o x402 e o MPP estão mais próximos da camada de handshake HTTP de pagamentos, abordando a questão de «como garantir que os pedidos sejam devolvidos com capacidade de pagamento».

O AP2 está mais próximo da autorização e da intenção confiável, abordando a questão: «Este agente tem o direito de gastar este dinheiro?»

A UCP e a ACP correspondem mais à camada de fluxo de trabalho, ocupando-se da descoberta, do checkout, das relações com os comerciantes e da transmissão de credenciais — questões que estão mais relacionadas com «quem controla o tráfego e a orquestração das transações».

Muitas empresas que suportam simultaneamente os protocolos x402, MPP, AP2 e UCP não o fazem por falta de clareza da sua parte, mas porque a arquitetura que acabará por prevalecer provavelmente abrangerá várias camadas e poderá até exigir a combinação de vários protocolos.

Portanto, se tivesse de resumir o meu pensamento anterior numa frase, diria que agora acredito ainda mais firmemente que, sem a interoperabilidade, esta onda de ecologia nem sequer teria surgido.

Olhando para a situação agora, o mercado está a confirmar ativamente essa avaliação.

Além disso, este acórdão é igualmente importante no contexto do comércio B2B em comparação com o retalho.

Porque, no mundo do retalho, pode de facto acabar por ser absorvido por algumas grandes plataformas e alguns fluxos de trabalho importantes; mas o mundo B2B não é assim.

As empresas operam, por natureza, num contexto em que coexistem múltiplas nuvens, vários métodos de pagamento, vários sistemas de fluxo de trabalho e vários sistemas de autorização de identidades.

Quem tentar utilizar um novo protocolo para reformular completamente toda a pilha empresarial provavelmente irá fracassar logo à partida.

O que os clientes B2B estão realmente dispostos a pagar não é, muitas vezes, «o protocolo único e correto», mas sim a capacidade de fazer com que os sistemas existentes funcionem num ambiente multiprotocolo.

É precisamente por esta razão que a interoperabilidade é mais crucial em contextos empresariais do que em contextos de consumo.

5. Não se trata apenas de uma competição de protocolos, mas sim de uma competição de pilhas em camadas

Assim que compreender esta questão como uma estrutura em camadas, muitos fenómenos que inicialmente pareciam caóticos passarão imediatamente a fazer sentido.

Na camada inferior encontra-se o protocolo de acesso pago.

Esta camada diz respeito à forma como os pedidos HTTP indicam que «é necessário efetuar o pagamento» e à forma como o cliente devolve as credenciais de pagamento após a transação.

O x402 e o MPP são os principais concorrentes neste contexto. A MPP está a tentar formalizar o código 402 numa semântica de autenticação HTTP mais oficial; enquanto o x402 visa, sobretudo, a «plataformização» do 402, recorrendo a cabeçalhos personalizados, facilitadores, abstrações de liquidação na cadeia e integração no ecossistema para o colocar em funcionamento numa primeira fase.

Uma é mais parecida com uma rota semântica padronizada, enquanto a outra assemelha-se a uma rota de distribuição de plataforma.

O nível seguinte é a autoridade para efetuar despesas, ou seja, «quem autorizou esta verba».

Esta vertente é o elemento-chave que muitas pessoas ainda não compreenderam totalmente.

Fazer com que as máquinas paguem não é assim tão difícil; o verdadeiro desafio é garantir que se pode confiar nas máquinas para autorizarem os pagamentos.

O AP2 é importante precisamente porque aborda não só a questão de «como pagar», mas também as obrigações, as credenciais verificáveis, a autenticidade e a responsabilização.

Os tokens de agente, a validação de instruções, as chaves de acesso e os sinais de contestação, nos quais a Visa e a Mastercard têm vindo a apostar fortemente, enquadram-se, na sua essência, nesta camada.

A camada seguinte é a do fluxo de trabalho e da distribuição.

Isto inclui a descoberta, o checkout, as relações com os comerciantes, a partilha de credenciais e a integração de interfaces de IA — questões que estão mais relacionadas com «quem controla o tráfego e a coordenação das transações».

A UCP e a ACP parecem estar mais a competir por esta camada.

No que diz respeito ao B2B, esta vertente poderá não ser tão dinâmica a curto prazo, mas o seu valor a longo prazo poderá ser muito elevado.

Porque, se no futuro cada vez mais software empresarial for coordenado, solicitado, adquirido e pago por agentes, quem dominar a linguagem do fluxo de trabalho não estará apenas a gerir um único pagamento, mas sim todo o fluxo de trabalho.

Depois de separar estas três camadas, vai perceber uma coisa muito simples: não há necessidade de esperar que um único protocolo abranja todas as questões.

Uma abordagem mais realista consiste em que estas três camadas se desenvolvam separadamente e, posteriormente, passem a interagir gradualmente.

Por essa razão, apostar em várias opções não é indecisão, mas sim racionalidade.

6. O verdadeiro risco do x402 pode não ser a regulamentação, mas sim os aspetos económicos da concorrência

Se nos limitarmos a reconhecer «a coexistência de vários protocolos», isso ainda não é suficientemente profundo.

O maior risco para o x402 pode não ser, em primeiro lugar, a regulamentação, mas sim a questão económica relacionada com a diferença entre o momento da verificação e o momento da utilização, decorrente do processo de verificação e liquidação em duas etapas.

Em termos simples, se a verificação do pagamento e a liquidação final não forem a mesma coisa, então, em ambientes reais da Internet caracterizados por elevada simultaneidade, tentativas repetidas, camadas de proxy e camadas de cache, haverá uma janela de oportunidade para «pagar uma vez, aceder várias vezes».

O ecossistema x402 está atualmente também a corrigir falhas, tais como a cache de liquidação, a extensão de idempotência e o identificador de pagamento, mas isso indica precisamente que a questão não é meramente teórica.

Por que é que isto é particularmente relevante para os leitores do setor B2B?

Porque o que o mundo B2B mais teme não é a incapacidade de criar uma demonstração apelativa, mas sim o facto de haver demasiados casos extremos e, assim que o produto entra em produção, começarem a surgir falhas.

À primeira vista, a monetização de APIs pode parecer apenas o pagamento de alguns cêntimos por pedido, o que é bastante insignificante; mas assim que o seu produto passa a cobrar por chamada, por resultado ou por fluxo de trabalho, a diferença entre «pagar uma vez e obter um» ou «pagar uma vez e obter muitos» deixa de ser apenas um pormenor do produto e passa a ser uma questão de vida ou morte.

Portanto, para que o x402 consiga realmente impor-se no setor B2B, um pré-requisito importante não é a narrativa, mas sim que esses mecanismos de segurança por defeito sejam suficientemente simples de utilizar; caso contrário, as empresas não se sentirão seguras ao redirecionar tráfego real para o sistema.

7. Os protocolos podem ser gratuitos, mas as portagens não vão desaparecer

Há mais um ponto que considero que vale a pena aprofundar neste artigo.

Muitos protocolos abertos acabam por chegar a um ponto bastante familiar: o próprio protocolo torna-se cada vez mais barato, ou mesmo gratuito, mas, paralelamente, surgirão verdadeiros «portões de cobrança».

O x402 não é diferente.

A própria norma enfatiza, sem dúvida, a abertura, a neutralidade e a ausência de taxas, mas isso não significa que a captura de valor vá desaparecer.

Se o x402 for bem-sucedido, o valor não permanecerá principalmente dentro do protocolo, mas migrará para facilitadores, carteiras, gestão de chaves, descoberta, motores de políticas e wrappers de confiança — estas camadas adjacentes.

Isto é especialmente importante no contexto B2B.

Uma vez que os clientes empresariais não irão reformular em grande escala todos os seus sistemas por causa de um novo protocolo; o que estão realmente dispostos a pagar é por quem os possa ajudar a organizar a orquestração, as políticas, os riscos, a conformidade, a auditoria, a liquidação e os limites de autorização num ambiente multiprotocolo.

Por outras palavras, os protocolos irão assemelhar-se cada vez mais às linguagens subjacentes, mas a capacidade de traduzir essas linguagens em funcionalidades «prontas para uso empresarial» irá transformar-se mais facilmente em novas plataformas e novos pontos de cobrança.

É também por isso que considero que, ao analisarmos o x402 hoje, não devemos concentrar-nos apenas em saber quem, entre a Coinbase, a Cloudflare ou a Stripe, se assemelha mais ao «protagonista».

O que realmente vale a pena observar é quem tem a melhor oportunidade de se posicionar nessas camadas adjacentes.

A Cloudflare detém uma posição na área da distribuição de tráfego e na periferia da rede; a Stripe detém uma posição na infraestrutura de pagamentos e nas relações com os comerciantes; a Visa e a Mastercard detêm posições nas credenciais, nos tokens de rede e na confiança dos consumidores; e a Google detém uma posição nos fluxos de trabalho e nas plataformas de pesquisa.

A verdadeira valorização pode não residir em «quem definiu a norma 402», mas sim em «quem integrou a norma 402 em sistemas empresariais de maior dimensão».

8. Conclusão

A Fundação x402 não está a afirmar que o x402 já se impôs em todos os protocolos de comércio agênico.

É um reconhecimento público de que esta geração de pagamentos a agentes não será um mundo de protocolo único desde o primeiro dia.

A Coinbase está a transferir o x402 para a Linux Foundation com o objetivo de o tornar mais uma camada pública neutra do que um produto exclusivo.

O facto de o Stripe apostar no MPP enquanto entra no x402 não é indecisão; é porque sabe que, neste momento, não se deve apostar apenas num dos lados.

A Cloudflare suporta ambos os sistemas em simultâneo porque é o que mais se aproxima do tráfego real.

As ações de empresas como a Google, a Visa, a Mastercard e a Adyen também apontam para o mesmo: primeiro, permitir que os sistemas funcionem em conjunto; depois, discutir quem, em última instância, ocupa cada camada.

E se deixarmos de olhar apenas para o retalho, esta conclusão torna-se ainda mais clara.

Porque quem primeiro poderá precisar destes protocolos não será necessariamente o carrinho de compras, mas sim o número crescente de softwares e serviços B2B que cobram por chamada, tarefa ou resultado.

O setor retalhista é certamente maior, mas o B2B muitas vezes revela as necessidades reais mais cedo e define mais rapidamente como será, em última análise, a infraestrutura.

No meu último artigo, coloquei a interoperabilidade no centro das atenções, e acredito que a resposta do mercado é agora bastante clara: sim, e até mais cedo do que eu pensava na altura.

Nesse sentido, a Fundação x402 não é o fim desta história.

Isso permite-nos simplesmente perceber mais cedo que o verdadeiro tema nunca foi «quem vai ganhar», mas sim «este mundo está destinado a tornar-se interoperável em primeiro lugar, e quem conseguirá ocupar a camada mais valiosa após a interoperabilidade».