Coinbase coloca o x402 em posição neutra Stripe aposta em ambos os lados fora do MPP

Autor: Charlie Liu, sócio na Generative Ventures

Os amigos que tenho vindo a seguir sobre agentic commerce estão a aumentar cada vez mais, mas os vários protocolos e players também estão a deixar toda a gente ainda mais baralhada.

Sobretudo na semana passada: toda a gente ainda estava ocupada a tentar perceber o MPP da Stripe / Tempo e, de repente, a Stripe acabou por se juntar ao x402 Foundation, do seu parceiro/concorrente Coinbase.

Além disso, a Cloudflare agora suporta os dois. A Google também está metida neste jogo, mas tem o seu próprio AP2 e UCP.

Também chegaram a Visa e a Mastercard, mas é evidente que não estão aqui para apoiar stablecoins.

A Linux Foundation definiu publicamente o x402 como um “quartel-general” neutro e governado pela indústria, em regime de co-gestão. A Cloudflare, por sua vez, colocou de forma explícita o x402 e o MPP, em simultâneo, no seu Agents SDK. A Stripe também escreveu publicamente que suporta simultaneamente MPP e x402.

Então afinal quem está em competição com quem, e quem está a sobrepor-se com quem?

Mas quanto mais olho para isto nos últimos dias, mais me parece que este “caos” não acontece porque o mercado não tem direção; acontece porque o mercado já está bastante claro — e, como eu tinha mencionado antes, isto desde o primeiro dia não vai ser unificado por um único protocolo de uma só vez.

Isto é mais como uma situação muito comum nas infraestruturas da Internet: camadas diferentes crescem em simultâneo, empresas diferentes apostam em camadas diferentes e, no fim, é a interoperabilidade que faz o ecossistema todo avançar primeiro e fazer as coisas funcionar.

A verdadeira história estratégica é perceber quem vai definir a camada de controlo predefinida para paid machine access na agentic web; e os players-chave, de forma evidente, estão todos a multi-home, porque todos ainda apostam que o verdadeiro gargalo futuro vai cair em autorização, distribuição ou liquidação.

1. Porque é que a Coinbase deixou o x402 Foundation a cargo da Linux?

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

Isto não é uma frase politicamente correcta; é uma lógica de normalização muito real.

A Linux Foundation foi muito clara nesta formulação: enfatiza neutralidade do prestador de serviços, governação comunitária, infraestrutura partilhada — e não “uma empresa lançou uma nova funcionalidade num produto”.

E mais importante: a página do x402 Foundation ainda indica que o projecto está em fase de construção, com mecanismos de governação e um conselho de administração ainda a ser montados.

Ou seja, esta acção não está primeiro a anunciar “o produto já está maduro”; está a anunciar “vamos dar a este protocolo uma casa neutra”.

A mensagem escondida por trás disto é, na realidade, bastante simples.

Se o x402 continuar a ter o rosto de uma funcionalidade de produto da Coinbase (por exemplo, o Base actual), então fornecedores de cloud, empresas de pagamentos, organizações de cartões e players orientados a plataformas — mesmo que tecnicamente queiram integrar — hesitarão politicamente.

Ninguém quer entregar a camada futura de paid access a uma única plataforma. Colocá-la sob a Linux Foundation não é porque a Coinbase não quer controlar; é precisamente porque quer que o x402 seja adoptado amplamente e, por isso, precisa primeiro de tirar o fardo de “isto é um protocolo da Coinbase”.

Isto é mesmo importante, porque muita gente ao olhar para acções como esta de fundação, tende a vê-las apenas como PR ou uma postura open source.

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

Sobretudo quando um padrão ainda está numa fase inicial, e ainda não existe um efeito de rede absoluto, a alegada “neutralidade e confiança” não é menos importante do que a elegância técnica.

Por outro lado, se no futuro o x402 conseguir tornar-se uma espécie de baseline de paid access nativo de HTTP, provavelmente não será porque o código é o mais bonito — mas porque foi capaz de baixar mais cedo os custos políticos em comparação com outras soluções.

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

2. O que é que a Stripe está realmente a fazer com o “vai e vem” entre os dois lados?

O player que vale mesmo a pena observar nesta história é, sem dúvida, a Stripe, porque as suas acções são as que mais facilmente deixam as pessoas confusas.

Por um lado, no dia 18 de Março, lançou de forma bem publicitada o MPP, embalando-o como um standard aberto de payments para máquinas.

Por outro lado, é também uma founding contributor do x402 Foundation e até a sua própria documentação suporta machine payments do x402.

A documentação da Cloudflare é ainda mais directa; chega mesmo a escrever de forma explícita que: o fluxo de pagamento central do MPP para o x402 é backward-compatible, e que um client MPP pode consumir directamente os serviços existentes do x402.

Se olharmos apenas por esta moldura — “competição de protocolos” — então a Stripe parece estar a lutar em ambos os lados.

Mas se elevássemos o ponto de vista um pouco mais, essa abordagem acaba por fazer ainda mais sentido do ponto de vista comercial.

Porque aquilo que a Stripe realmente quer proteger pode não ser apenas o próprio 402 handshake.

O que ela quer proteger é aquelas camadas por cima do handshake: credenciais, compliance, risco, reporting, tax, refunds e merchant integration.

A Stripe não parece ser uma verdadeira crente num único protocolo; parece mais empenhada em garantir que, independentemente de qual handshake padrão venha a vencer, a Stripe continue a ser a camada abstracta por defeito para agent payments.

Suportar x402 é para não ficar de fora do ecossistema aberto; lançar MPP é para participar na definição de semânticas de base; empurrar ACP e Shared Payment Tokens mais acima é para proteger uma camada de valor ainda mais espessa: fluxos de trabalho e credenciais de pagamento.

Portanto, onde a Stripe é mais “estranha” nesta história, é também onde é mais honesta.

Ela não está a fingir que no futuro rapidamente vai sobrar apenas um protocolo. Está a dizer-te através das acções: pelo menos nesta fase, ninguém deveria apostar apenas num dos lados.

3. Isto é, no fundo, uma história de infraestruturas B2B

Cada vez mais me convenço de que muitos media estão a desviar o foco desta questão.

Quando se fala em agent payments, o mais comum é pensar no retalho: a IA compra-te bilhetes, reserva-te hotéis, faz-te a encomenda, guia-te no checkout.

Mas se olhares para os cenários que já estão efectivamente abertos ao público, já implementados e com cheirinho real de infraestruturas, a primeira coisa a arrancar não é o checkout de retalho — são antes os paid access B2B mais aborrecidos e mais reais: APIs pagas, dados pagos, ferramentas pagas, sessões de browser pagas, workflows pagas de agentes.

A Cloudflare agora suporta publicamente cobrar conteúdos HTTP, APIs e MCP tools com x402 e MPP.

O caminho de adopção mais forte do x402 está em APIs e tools pagas de developer-to-developer, porque “no account + pay-per-request” aqui não é apenas um slogan; é mesmo uma implementação operacional.

A mudança por trás disto é enorme.

No passado, quando uma API era paga, normalmente exigia percorrer uma série completa de fluxos “amigáveis para humanos”: abrir conta, ligar billing, emitir API key, definir limites, fazer reconciliações e só depois tratar as permissões de pagamento.

Para humanos isso já é aborrecido o suficiente; para agentes, ainda é mais desconfortável.

O que torna o x402 mais atractivo não é por ser “mais crypto”, nem por ser “mais IA”, mas por tentar voltar a colocar o “acesso pago” dentro do próprio HTTP — fazendo com que o controlo de admissão e a negociação de pagamento aconteçam como se fossem um request-response normal.

O servidor devolve 402 e diz-te quanto vale esta chamada; o cliente paga e depois tenta novamente o mesmo request usando as credenciais de pagamento.

Se olhares para este modelo do ponto de vista de software B2B e de machine-to-machine access, ele encaixa melhor do que numa perspectiva de retalho.

E quanto mais te aproximas do lado B2B, mais evidentes ficam as vantagens do x402, e mais as suas fragilidades perdem impacto.

Porque no consumer commerce, refund, chargebacks, merchant-of-record, consumer protection e atribuição de responsabilidade são todos problemas difíceis; já nas chamadas de API B2B e no acesso entre máquinas, a importância destes problemas diminui claramente.

Em contrapartida, a necessidade real é: “sem conta, pagar por chamada, obter o resultado e seguir em frente”.

O retalho é, claro, maior, mais barulhento e chama mais atenção; mas aquilo que define como o protocolo “deve ser” raramente é o cenário mais barulhento — costuma ser o cenário que expõe mais cedo necessidades reais.

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

4. A evolução da indústria validou a minha ideia anterior de interoperability

No meu artigo anterior, a aposta mais central era a interoperabilidade.

Na altura, essa conclusão tinha ainda um certo sabor de “isto deveria ser assim em termos de arquitectura”.

Agora, parece cada vez mais uma restrição do mundo real, porque o mercado público já está a dar voto com os pés.

A Cloudflare não escolheu um lado: suporta directamente em simultâneo x402 e MPP, e ainda fez mapeamentos de compatibilidade de forma explícita.

A Google participa em x402 e, em paralelo, 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 “all in one winner”; estão a entrar em x402 e, em simultâneo, a reforçar com agent tokens, autenticação, validação de instruções e dispute signals.

As multi-apostas de gigantes são uma decisão racional, não uma hipocrisia comercial.

Porque é que isto acontece? Porque estes protocolos, na realidade, 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 a questão de “como é que um request consegue trazer capacidade de pagamento consigo”.

AP2 está mais perto de autorização e intenções confiáveis; resolve a questão de “este agent tem, de facto, qualificação para gastar este dinheiro de forma verificável”.

UCP e ACP são ainda mais como uma camada de workflow: tratam de discovery, checkout, relações com comerciantes e transmissão de credenciais — problemas mais acima.

Muitas empresas suportam simultaneamente x402, MPP, AP2 e UCP não porque não saibam o que estão a fazer, mas porque a arquitectura que acaba por vencer muito provavelmente atravessa múltiplas camadas e, até, precisa de múltiplos protocolos em conjunto.

Por isso, se for necessário resumir em uma frase olhando para trás a minha conclusão anterior, eu acredito ainda mais agora que, sem interoperabilidade, esta vaga de ecossistemas nem sequer arrancaria.

Agora, ao que parece, o mercado está a validar activamente este ponto.

Mais além, esta conclusão é importante tanto para B2B vs retalho.

No mundo do retalho, é possível que no fim acabe por ser absorvido por poucas grandes plataformas e por poucos grandes workflows; mas o mundo B2B não funciona assim.

Empresas já vivem na realidade de existir multi-cloud, múltiplos métodos de pagamento, sistemas de workflows múltiplos e sistemas de identidades e permissões múltiplos.

Quem tentar derrubar de uma só vez e recriar completamente toda a stack empresarial com um novo protocolo, provavelmente morre primeiro.

Os clientes B2B que realmente estão dispostos a pagar, normalmente não compram “o único protocolo correcto”; compram “a capacidade de manter os sistemas existentes a funcionar num ambiente multi-protocolo”.

E este raciocínio é precisamente o que faz com que interoperabilidade seja, em cenários empresariais, mais “duro” do que em consumer.

5. Isto não é apenas competição de protocolos; é competição de stack depois de estratificar camadas

Assim que entendes isto como uma stack por camadas, muitos fenómenos que pareciam “baralhados” ficam imediatamente mais claros.

A camada mais abaixo é o paid access handshake.

Esta camada preocupa-se com: como um request HTTP expressa “é necessário pagar” e como o cliente, depois de pagar, consegue trazer a credencial de pagamento de volta.

x402 e MPP atacam principalmente aqui. O MPP está a tentar levar 402 para uma semântica de autenticação HTTP mais formal; e o x402 parece mais “platformizar” o 402, através de headers personalizados, facilitators, abstracção de liquidação on-chain e integração com ecossistemas, para que avance primeiro.

Um caminho mais orientado a semântica normalizada; outro mais orientado a distribuição de plataforma.

Uma camada acima é authority to spend, ou seja, “quem autorizou este pagamento”.

É aqui que muita gente ainda não percebeu totalmente como é a peça-chave.

Máquinas pagam; isso não é assim tão difícil. O difícil é conseguir que as máquinas sejam autorizadas de forma confiável para pagar.

O AP2 é importante por resolver não apenas “como pagar”, mas sim mandates, verifiable credentials, authenticity e accountability.

Os agent tokens e as instruction validation, passkeys e dispute signals com que a Visa e a Mastercard têm reforçado recentemente também, na essência, estão aqui.

Uma camada ainda acima é workflow e distribution.

Ou seja: discovery, checkout, relação com comerciantes, partilha de credenciais, integração da superfície de IA — tudo o que está mais perto de “quem controla o fluxo de tráfego e a orquestração de transacções”.

UCP e ACP parecem estar a disputar esta camada.

Para B2B, esta camada pode não ser tão entusiasmante a curto prazo, mas a longo prazo o valor pode ser muito alto.

Porque se no futuro cada vez mais software empresarial for coordenado, chamado, comprado e pago por agentes, então quem dominar a linguagem de workflow não vai apenas controlar um pagamento — vai controlar o workflow inteiro.

Assim que separas estas três camadas, aparece um facto muito simples: não há realmente necessidade de esperar que um protocolo encapsule todas as questões.

O caminho mais realista é: estas três camadas crescem primeiro cada uma por si e depois, através da interoperabilidade, vão-se juntando devagar até encaixarem.

E é exactamente por isso que fazer apostas a vários níveis não é indecisão; é racionalidade.

6. O verdadeiro risco do x402 pode não ser a regulação; pode ser a economia por trás da concorrência

Se apenas reconhecermos “existem múltiplos protocolos em paralelo”, ainda não é suficientemente profundo.

O maior risco do x402 pode não ser primeiro a regulação; pode ser a economia de verify–settle em duas etapas, criando time-of-check/time-of-use.

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

O ecossistema do x402 também está a tentar tapar buracos, como settlement cache, idempotency extension e payment identifier; mas isso mostra precisamente que o problema não é apenas teórico.

Porque é que isto é particularmente relevante para leitores B2B?

Porque no mundo B2B, o que se teme nunca é “não conseguir construir demos bonitas”; o que se teme são tantos edge cases, que no fim — assim que entrares em produção — começam a vazar.

A monetização por API, à primeira vista, parece apenas “alguns cêntimos por request”. Mas, se o teu produto cobra por chamada, por resultado ou por workflow, então “pagar uma vez e obter uma vez” versus “pagar uma vez e obter muitas vezes” deixa de ser um detalhe do produto e torna-se uma linha de vida ou de morte.

Portanto, se no futuro o x402 conseguir mesmo avançar no B2B, uma condição importante não é apenas a narrativa; é que esses mecanismos default-safe sejam implementados de forma suficientemente “à prova de parvo” — caso contrário, as empresas não vão confiar em ligar tráfego real.

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

Há mais um ponto: acho que vale a pena explicar isto bem nesta peça.

Muitos protocolos abertos acabam por chegar a um lugar familiar: o protocolo em si fica cada vez mais barato, até gratuito; mas as verdadeiras portagens crescem ao lado.

O x402 é igual.

O standard, claro, enfatiza abertura, neutralidade e 0 fees embutidos no próprio standard; mas isto não significa que a value capture desaparece.

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

Para B2B isto é especialmente importante.

Porque clientes empresariais não vão pagar ou fazer grandes remodelações só por causa de um novo protocolo; o que realmente estão dispostos a pagar é quem lhes consegue tratar, num ambiente multi-protocolo, toda a orquestração, política, risco, compliance, auditoria, liquidação e limites de permissões.

Dito de outra forma: o protocolo vai ficando cada vez mais como uma linguagem de base; mas a camada que traduz essa linguagem para uma capacidade de “ser seguro para a empresa colocar em produção” é que tem mais probabilidade de se tornar uma nova plataforma e uma nova portagem.

É também por isso que eu acho que, ao observar o x402 hoje, não devemos focar apenas em Coinbase, Cloudflare e Stripe — em quem parece mais “protagonista”.

O que merece ser observado é quem tem mais oportunidade de ficar nestas camadas adjacentes.

A Cloudflare tem posições de edge e de distribuição de tráfego; a Stripe tem posições de infraestrutura de pagamento e relação com comerciantes; a Visa e a Mastercard têm posições de credenciais, network tokens e consumer trust; a Google tem posições na superfície de workflow e discovery.

A captura real de valor não precisa necessariamente acontecer em “quem define o 402”; é mais provável que aconteça em “quem liga o 402 ao sistema empresarial maior”.

8. Conclusão

A história do x402 Foundation não é a de anunciar 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, nunca será um mundo de um único protocolo.

Ao entregar o x402 à Linux Foundation, a Coinbase fá-lo para que se pareça mais com uma camada pública neutra, e não com um produto exclusivo.

A Stripe, ao mesmo tempo que promove o MPP e se junta ao x402, não está a indecidir; está porque sabe que, neste momento, não deve apostar só num lado.

A Cloudflare suporta as duas coisas porque está mais perto do tráfego real.

Os movimentos de Google, Visa, Mastercard e Adyen também estão todos a indicar a mesma coisa: primeiro fazer com que os sistemas sejam interoperáveis; depois discutir quem acaba por ocupar que camada no fim.

E se tirares a perspectiva do retalho, esta conclusão encaixa ainda melhor.

Porque os primeiros a precisar destes protocolos podem não ser os carrinhos de compras; podem ser cada vez mais software e serviços B2B que cobram por chamada, por tarefa e por resultado.

O retalho é, claro, maior; mas o B2B expõe mais cedo as necessidades reais e define mais cedo como deve ser a última infraestruturas.

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

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

É apenas o que nos faz ver mais cedo que o verdadeiro tema nunca foi “quem vai vencer”; foi e é “este mundo tem de ser interoperável primeiro — e quem vai conseguir, depois da interoperabilidade, ocupar a camada que é mais valiosa”.