A Coinbase coloca o x402 em posição neutra, enquanto a Stripe continua a apostar em ambos os lados fora do MPP

Autor: Charlie, responsável da OSL para a América, Venture Partner na Generative Ventures. Antes, foi vice-presidente da criptomoeda unicorn Strike (participou no projeto de lei sobre Bitcoin em El Salvador e foi responsável pelos negócios de rede Lightning de Bitcoin na América Latina e por pagamentos de stablecoins), analista de macro e moedas na Franklin Templeton, um fundo de escala da ordem dos biliões, e membro inicial do gigante de pagamentos Adyen.

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

Tenho cada vez mais amigos a acompanhar o agentic commerce, mas os vários protocolos e intervenientes também fazem com que as pessoas fiquem cada vez mais baralhadas.

Sobretudo na semana passada: as pessoas ainda estavam ocupadas a perceber o MPP da Stripe / Tempo e, de repente, a Stripe já entrou na x402 Foundation do concorrente Coinbase.

E além disso, a Cloudflare agora suporta as duas opções. A Google também está neste enredo, mas tem também o AP2 e o UCP.

A Visa e a Mastercard também já apareceram, mas é óbvio que não vieram apoiar as stablecoins.

A Linux Foundation definiu publicamente o x402 como um “quartel-general” neutro, governado conjuntamente e pela indústria; a Cloudflare, por sua vez, colocou explicitamente o x402 e o MPP em simultâneo no seu Agents SDK, e a Stripe também escreveu publicamente que suporta simultaneamente o MPP e o x402.

No fim, afinal com quem está isto a competir, e entre quem é que há sobreposição?

Mas, quanto mais olho para isto nestes dias, mais sinto que este “caos” não acontece por falta de direção no mercado, e sim porque o mercado já está muito claro — e, tal como eu antes talvez tenha entendido mal a intenção original do x402: desde o primeiro dia, isto não vai ser unificado de uma só vez por um único protocolo.

Parece-se mais com um cenário muito comum na infraestrutura da Internet: camadas diferentes crescem em paralelo, empresas diferentes apostam em camadas diferentes e, no fim, é a interoperabilidade que faz o sistema todo arrancar primeiro.

A verdadeira história estratégica é: quem define a camada de controlo por defeito do paid machine access na agentic web; e, além disso, os principais intervenientes claramente estão em multi-home, porque todos ainda estão a apostar onde é que o verdadeiro gargalo do futuro vai cair — na autorização, na distribuição ou no settlement.

I. Porque é que a Coinbase deixou ir e passou a x402 para a Linux Foundation?

Se o x402 for apenas um protocolo da Coinbase, é difícil que se torne uma opção por defeito da indústria.

Isto não é uma frase de correção política; é uma lógica de normalização muito realista.

A Linux Foundation foi desta vez muito clara: enfatiza a neutralidade do fornecedor de serviços, a governação pela comunidade e a infraestrutura partilhada, e não “uma empresa lançou uma nova funcionalidade de produto”.

Mais importante ainda: na página da x402 Foundation, agora até está escrito que o projeto se encontra na fase de constituição, e que os mecanismos de governação e o conselho de administração ainda estão a ser montados.

Ou seja, esta ação não é primeiro um anúncio de “o produto já amadureceu”, mas sim um anúncio de “vamos dar a este protocolo uma casa neutra”.

A mensagem implícita por trás é, na verdade, muito simples.

Se o x402 continuar a crescer com o rosto de uma funcionalidade de produto da Coinbase (por exemplo, a Base, neste momento), então fornecedores de cloud, empresas de pagamentos, organizações de cartões e players do tipo plataforma, mesmo que tecnicamente estejam dispostos a integrar, hesitarão politicamente.

Ninguém quer entregar a camada futura de paid access a uma única plataforma. Colocar isto sob a Linux Foundation não é porque a Coinbase não queira controlar; é precisamente porque quer que o x402 seja amplamente adotado, pelo que tem de, primeiro, retirar o peso de “isto é um protocolo da Coinbase”.

Isto é, aliás, muito importante, porque muitas pessoas ao verem ações como estas de uma fundação tendem a vê-las apenas como PR ou como postura de open source.

Mas numa guerra de protocolos, a governação é parte do produto.

Especialmente quando um standard ainda está na fase inicial e ainda não tem efeitos de rede absolutamente decisivos, a chamada “neutralidade e confiança” não é menos importante do que a elegância técnica.

Por outro lado, se o x402 realmente conseguir, no futuro, tornar-se um certo baseline de paid access “nativo de HTTP”, é muito provável que não seja porque o seu código seja o mais bonito, mas sim porque baixou primeiro os custos políticos em relação a outras soluções.

Por outras palavras: aqui, a governação não é um papel secundário; a governação, por si só, é o motor de crescimento.

II. O que é que a Stripe anda a fazer afinal com o seu “vai e vem” para os dois lados?

O interveniente que, sem dúvida, merece mais atenção nesta ronda é a Stripe, porque as suas ações são as que mais facilmente confundem as pessoas.

Por um lado, a 18 de março lançou com grande destaque o MPP, embalando-o como um standard aberto para pagamentos de máquinas.

Por outro lado, é também founding contributor da x402 Foundation, e os seus próprios documentos também suportam pagamentos de máquinas com x402.

A documentação da Cloudflare é ainda mais direta: chega mesmo a escrever explicitamente que o core payment flow do MPP para o x402 é backward-compatible, e que o cliente MPP pode consumir diretamente os serviços existentes de x402.

Se olharmos apenas pelo quadro de “competição de protocolos”, a Stripe parece estar a jogar para os dois lados.

Mas se levantarmos um pouco mais a perspetiva, esta abordagem faz, na verdade, todo o sentido do ponto de vista do negócio.

Porque o que a Stripe realmente quer proteger pode não ser apenas o handshake 402 em si.

O que ela quer proteger são aquelas camadas acima do handshake: credentials, compliance, risk, reporting, tax, refunds e integração com merchants.

A Stripe não parece ser uma verdadeira crente de um único protocolo; parece mais preocupada em garantir que, independentemente de qual standard de handshake sair vencedor no fim, a Stripe continue a ser a camada abstrata por defeito para agent payments.

Suportar x402 é para não ficar fora do ecossistema aberto; promover o MPP é para participar na definição do significado semântico de base; e, ao promover ACP e Shared Payment Tokens, é para proteger uma camada de maior valor — o fluxo de trabalho e as credenciais de pagamento.

Por isso, o que há de mais “estranho” na Stripe nesta ronda é, na verdade, o que há de mais honesto.

Ela não está a fingir que, no futuro, vai sobrar rapidamente apenas um protocolo. Está a dizer-te, por ação, que pelo menos nesta fase ninguém deveria apostar apenas num lado.

III. Isto é, na verdade, uma história de infraestrutura B2B

Cada vez mais sinto que muitos órgãos de comunicação social estão a colocar o foco no sítio errado.

Quando se fala em agent payments, a primeira coisa que as pessoas pensam é quase sempre retalho: a IA ajuda-te a comprar bilhetes de avião, a reservar hotéis, a fazer encomendas e a concluir checkout.

Mas se olharmos para os cenários que já estão realmente implementados de forma pública e que têm mesmo um cheiro a infraestrutura, o primeiro a arrancar não é o checkout de retalho, mas sim um paid access B2B mais “chato” e mais real: APIs pagas, dados pagos, ferramentas pagas, sessões de browsers pagas, e workflows de agent pagos.

A Cloudflare está agora a suportar publicamente a cobrança por HTTP content, APIs e MCP tools usando x402 e MPP.

O caminho de adoção mais forte para o x402 está em APIs e tools pagas developer-to-developer, porque “no account + pay-per-request” aqui não é um mero truque — é uma implementação praticável.

A mudança por trás disto é, na verdade, bastante grande.

No passado, para uma API ser paga, normalmente era necessário passar por um conjunto completo de processos “amigáveis para humanos”: abrir conta, associar billing, emitir uma API key, definir limites, fazer reconciliação e, só depois, tratar as permissões de pagamento.

Para pessoas, isso já é suficientemente irritante; para agents, ainda mais.

O ponto mais atrativo do x402 não é ser “mais crypto”, nem “mais AI”, mas sim a tentativa de voltar a colocar “paid access” dentro do próprio HTTP, fazendo com que o controlo de acesso e a negociação de pagamento aconteçam como uma request-response normal.

O servidor devolve um 402, dizendo-te quanto vale este pedido; o cliente paga e depois volta a tentar o mesmo pedido com a credencial de pagamento.

Se olhares para este modelo do ponto de vista de software B2B e de acesso machine-to-machine, ele é muito mais natural do que do ponto de vista do retalho.

E, quanto mais olhamos para o lado B2B, mais clara fica a vantagem do x402, e mais as limitações perdem gravidade.

Porque, no consumer commerce, reembolsos, chargebacks, merchant-of-record, proteção do consumidor e atribuição de responsabilidade são problemas difíceis; mas, em chamadas a APIs e ferramentas B2B, a importância desses problemas diminui claramente.

Em vez disso, a necessidade real é: “sem conta, paga por chamada, obtém o resultado e segue”.

O retalho é certamente maior, mais barulhento e mais fácil de chamar a atenção; mas quem define como deve ser um protocolo, muitas vezes, não é no cenário mais barulhento — é no primeiro cenário que expõe necessidades reais.

Para esta vaga de agent payments de hoje, esse cenário provavelmente não é carrinho, mas sim cada vez mais paid access entre softwares, entre agents e entre workflows.

IV. O desenvolvimento da indústria validou a minha opinião anterior sobre interoperabilidade

No meu artigo anterior, a conclusão mais central era a interoperabilidade.

Na altura, essa conclusão ainda tinha um certo sabor de “deveria ser assim do ponto de vista da arquitetura”.

Agora, parece cada vez mais uma restrição imposta pela realidade, porque o mercado público já está a votar com os pés.

A Cloudflare não escolheu um lado: suportou simultaneamente x402 e MPP e fez mapeamentos de compatibilidade explícitos.

A Google participa no x402 e, ao mesmo tempo, continua a avançar com AP2 e UCP.

A Visa e a Mastercard também não expressaram a sua estratégia com uma postura de “all in one winner”; pelo contrário, por um lado juntaram-se ao x402 e, por outro, intensificaram a aposta em agent tokens, validação de identidade, validação de instruções e dispute signals.

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

Porquê que isto acontece? Porque esses protocolos simplesmente nem sequer estão na mesma camada.

Pelo menos até agora, x402 e MPP estão mais perto da camada de paid HTTP handshake: resolvem “como fazer com que o pedido venha com capacidade de pagamento”.

AP2 aproxima-se da autorização e de intenções confiáveis: resolve “se este agent tem ou não autorização confiável para gastar este dinheiro”.

UCP e ACP são mais como camadas de workflow, para tratar questões mais acima: discovery, checkout, relação com merchants e transmissão de credenciais.

Muitas empresas suportam simultaneamente x402, MPP, AP2 e UCP não porque não saibam o que estão a fazer, mas porque a arquitetura que ganha no fim muito provavelmente é uma arquitetura que atravessa várias camadas, e até exige que múltiplos protocolos se completem.

Por isso, se quiser usar uma frase para rever a minha opinião anterior, estou agora ainda mais convencido de que, sem interoperabilidade, esta onda de ecossistema nem sequer se conseguiria erguer.

Agora, o mercado está a validar ativamente esta conclusão.

Mais ainda: esta conclusão é também importante para B2B vs retalho.

Porque no mundo do retalho, talvez no fim tudo seja absorvido por poucos grandes players de plataforma e por poucos grandes workflows; mas no mundo B2B não é assim.

As empresas já vivem, por natureza, na realidade de coexistirem múltiplas clouds, múltiplos métodos de pagamento, múltiplos sistemas de workflows e múltiplos sistemas de permissões de identidade.

Quem tenta usar um novo protocolo para derrubar e recomeçar toda a stack da empresa de uma só vez, muito provavelmente morre primeiro.

O que o cliente B2B está realmente disposto a comprar, na maioria das vezes, não é “o único protocolo correto”, mas sim “a capacidade de permitir que os sistemas existentes continuem a funcionar num ambiente multi-protocolo”.

E esta lógica é precisamente algo em que interoperabilidade é mais “forte” em cenários empresariais do que em cenários de consumer.

V. Isto não é competição apenas de protocolos; é competição de stack depois de dividir por camadas

Assim que começas a entender isto como uma stack por camadas, muitos fenómenos que antes pareciam confusos alinham-se imediatamente.

A camada mais de base é o paid access handshake.

Nessa camada, importa: como é que o HTTP request expressa “aqui é preciso pagar” e como é que o cliente, depois de pagar, leva de volta as credenciais de pagamento.

x402 e MPP jogam principalmente aqui. O MPP tenta “puxar” o 402 para uma semântica de autenticação HTTP mais formal; enquanto o x402 parece “platformizar” o 402, através de headers personalizados, facilitator, abstração de settlement on-chain e integração no ecossistema, para que este possa arrancar primeiro.

Uma rota mais orientada para semânticas padronizadas; uma rota mais orientada para distribuição por plataforma.

A camada acima é authority to spend, ou seja, “quem autorizou este dinheiro”.

É aqui que está a chave que muitas pessoas ainda não perceberam completamente.

As máquinas conseguem pagar, e isso não é tão difícil; o difícil é conseguirem ser autorizadas de forma confiável a pagar.

AP2 é importante precisamente porque não trata apenas de “como pagar”, e sim resolve mandates, verifiable credentials, authenticity e accountability.

Os agent tokens, validação de instruções, passkeys e dispute signals que a Visa e a Mastercard têm vindo a reforçar recentemente, no fundo, também estão aqui.

A camada seguinte é workflow e distribution.

Ou seja: discovery, checkout, relação com merchants, partilha de credenciais, integração da AI surface — tudo o que está mais perto de “quem controla o fluxo e a orquestração das transações”.

UCP e ACP parecem estar a disputar esta camada.

Para B2B, esta camada não tem muita agitação a curto prazo, mas a longo prazo pode ter um valor muito alto.

Porque, se no futuro cada vez mais software empresarial for coordenado, chamado, comprado e pago por agents, então quem controla a linguagem do workflow não está apenas a controlar um pagamento — está a controlar o workflow inteiro.

Quando separas estas três camadas, descobres um facto muito simples: não há necessidade de esperar que um protocolo englobe todos os problemas.

O caminho mais realista é: primeiro as três camadas crescem cada uma por si e, depois, é a interoperabilidade que as vai juntando lentamente.

E é precisamente por isso que apostar em várias frentes não é hesitação, é racional.

VI. O verdadeiro risco do x402: talvez não seja a regulação, mas sim a economia do concurrency em cenários de “verify–settle” em duas etapas

Se apenas reconhecermos “existem vários protocolos em simultâneo”, isso ainda não é o suficiente.

O maior risco do x402 talvez não seja em primeiro lugar a regulação, mas sim a economia do time-of-check/time-of-use criada pela separação em duas etapas de verify–settle.

Em termos simples: se a validação do pagamento e o settlement final não forem a mesma coisa, então, em ambientes reais de Internet com alta concorrência, retries, camadas de proxy e camadas de cache, surge uma janela de “pagar uma vez, aceder várias vezes”.

O ecossistema do x402 está agora a tapar buracos, por exemplo settlement cache, idempotency extension e payment identifier, mas isto mesmo mostra que o problema não é apenas teórico.

Porque é que isto deve ser particularmente do interesse de leitores B2B?

Porque no mundo B2B, o que mais se teme nunca é não conseguir fazer um demo bonito; o que se teme é haver demasiados casos-limite e, por fim, quando entra para produção, começar a “fugir”.

A monetização de APIs parece, à superfície, que é “alguns cêntimos por pedido”, o que é leve; mas, assim que o teu produto é cobrado por chamada, por resultado ou por workflow, a diferença entre “pagar uma vez e obter uma vez” e “pagar uma vez e obter muitas vezes” deixa de ser detalhe de produto — passa a ser uma linha de vida/morte.

Por isso, se no futuro o x402 realmente conseguir avançar no B2B, um pré-requisito importante não é o narrative, mas sim que estes mecanismos default-safe sejam feitos de forma suficientemente “idiota”, ou seja, sem complicações — caso contrário, as empresas não vão ficar tranquilas ao trazer tráfego real.

VII. Os protocolos podem ser gratuitos, mas os pontos de cobrança não desaparecem

Ainda há mais um ponto que eu acho que vale a pena explicar claramente aqui.

Muitos protocolos abertos acabam por ir parar a um lugar muito conhecido: o próprio protocolo fica cada vez mais barato, até gratuito, mas os verdadeiros pontos de cobrança crescem ao lado.

O x402 é igual.

O standard, claro, enfatiza abertura, neutralidade e 0 fees embutidos no standard, mas isso não significa que desapareça a value capture.

Se o x402 tiver sucesso, o valor não ficará principalmente dentro do protocolo; vai migrar para camadas adjacentes: facilitators, carteiras e key management, discovery, policy engine, trust wrapper e afins.

Isto é especialmente importante para B2B.

Porque os clientes empresariais não vão reformar em larga escala todo o conjunto de sistemas apenas por causa de um novo protocolo; o que eles realmente estão dispostos a pagar é por quem consegue ajudá-los a tratar, num ambiente multi-protocolo, as tarefas incómodas de orquestração, policy, risk, compliance, audit, settlement e limites de permissões.

Dito de outra forma: o protocolo vai ficando cada vez mais como uma linguagem base, mas a camada que traduz essas linguagens em “capacidade de colocar em produção com confiança para empresas” é a que, na prática, se torna mais facilmente uma nova plataforma e um novo ponto de cobrança.

É também por isso que eu sinto que, ao olharmos para o x402 hoje, não devemos apenas focar em quem parece mais “o protagonista”: Coinbase, Cloudflare ou Stripe.

O que verdadeiramente vale a pena observar é quem tem mais probabilidade de se posicionar sobre essas camadas adjacentes.

A Cloudflare tem posições de edge e distribuição de tráfego; a Stripe tem posições em infraestrutura de pagamentos e relações com merchants; a Visa e a Mastercard têm posições em credenciais, network tokens e consumer trust; a Google tem posições em workflow e discovery surface.

A verdadeira captura de valor pode não acontecer necessariamente em “quem define o 402”; é mais provável que aconteça em “quem conseguiu integrar o 402 dentro de sistemas empresariais maiores”.

VIII. Conclusão

O caso da x402 Foundation não é o anúncio de que o x402 já venceu em todos os protocolos de agentic commerce.

É um reconhecimento público de que esta geração de agent payments, desde o primeiro dia, não vai ser um mundo de protocolo único.

Ao entregar o x402 à Linux Foundation, a Coinbase está a fazê-lo parecer mais como uma camada pública neutra, e não como um produto exclusivo.

Quando a Stripe empurra o MPP e, ao mesmo tempo, entra na x402, não é hesitação; é porque sabe que, neste momento, não se deve apostar apenas num lado.

A Cloudflare suporta as duas soluções em simultâneo porque está a chegar mais perto do tráfego real.

As ações de Google, Visa, Mastercard e Adyen também mostram a mesma coisa: primeiro fazer com que os sistemas sejam interoperáveis; só depois discutir quem consegue ficar com que camada por fim.

E, se deslocarmos a perspetiva para fora do retalho, esta conclusão faz ainda mais sentido.

Porque as primeiras pessoas que precisam destes protocolos nem sempre são os carrinhos; cada vez mais são softwares e serviços B2B cobrados por chamada, por tarefa e por resultado.

O retalho, claro, é maior; mas B2B costuma expor necessidades reais mais cedo e define mais cedo como é que a infraestrutura final deve ser.

No meu artigo anterior, coloquei interoperabilidade no centro e, acho que agora a resposta do mercado é muito clara: sim — e até mais cedo do que eu pensava naquela altura.

Neste sentido, a x402 Foundation não é o fim desta história.

É apenas um passo que nos faz ver mais cedo que o tema verdadeiro nunca foi “quem vai vencer”, mas sim “este mundo está destinado a ser interoperável primeiro, e depois da interoperabilidade, quem consegue ocupar a camada que tem mais valor”.