Coinbase lleva a x402 a una posición neutral, mientras que Stripe continúa apostando por ambos lados fuera de MPP.

Autor: Charlie, director de OSL Americas, socio de riesgo en Generative Ventures. Exvicepresidente de Strike, la empresa unicornio de criptomonedas (que participó en la ley de Bitcoin de El Salvador y fue responsable de la red Bitcoin Lightning Network de América Latina y del negocio de pagos con stablecoins), analista macroeconómico y de divisas en el fondo multimillonario Franklin Templeton, y uno de los primeros miembros del gigante mundial de pagos Adyen.

El artículo refleja las opiniones personales del autor y no representa la postura de las empresas relacionadas.

Últimamente, cada vez más personas se han interesado por el comercio entre agentes, pero los diversos protocolos y participantes se han vuelto cada vez más confusos.

Especialmente la semana pasada, mientras todos estaban ocupados en comprender el MPP de Stripe/Tempo, Stripe se unió inesperadamente a la Fundación x402 de su competidor Coinbase.

Además, Cloudflare ahora es compatible con ambos sistemas. Google también participa, pero tiene su propio AP2 y UCP.

Visa y Mastercard también se han sumado, pero está claro que no están ahí para apoyar las stablecoins.

La Linux Foundation define públicamente x402 como un "campo base" neutral y cogobernado por la industria, mientras que Cloudflare ha incluido explícitamente tanto x402 como MPP en su propio SDK de agentes, y Stripe también ha declarado públicamente que admite tanto MPP como x402.

¿Quién compite con quién y quién se solapa con quién?

Sin embargo, cuanto más lo observo últimamente, más me doy cuenta de que este "caos" no se debe a que el mercado carezca de dirección, sino a que el mercado ya es muy claro. Como ya mencioné en x402, es posible que hayamos malinterpretado su intención original: desde el primer día, este asunto no se unificaría mediante un único protocolo de una sola vez.

Se asemeja a una situación común en la infraestructura de internet: diferentes capas se desarrollan simultáneamente, diferentes empresas apuestan por diferentes capas y, en última instancia, la interoperabilidad hará que todo funcione.

La verdadera cuestión estratégica radica en quién definirá la capa de control predeterminada para el acceso de pago a las máquinas en la web de agentes; y los actores clave están claramente diversificando sus estrategias, ya que todos siguen apostando por dónde se producirá el verdadero cuello de botella: la autorización, la distribución o la liquidación.

1. ¿Por qué Coinbase cedió la Fundación x402 a Linux?

Si x402 fuera solo el protocolo de Coinbase, sería difícil que se convirtiera en la opción predeterminada de la industria.

Esto no es una afirmación políticamente correcta, sino más bien una lógica de estandarización realista.

La declaración de la Fundación Linux en esta ocasión es muy clara; hace hincapié en la neutralidad de los proveedores de servicios, la gobernanza de la comunidad y la infraestructura compartida, en lugar de afirmar que "cierta empresa ha lanzado una nueva función a su producto".

Más importante aún, la página de la Fundación x402 indica actualmente que el proyecto se encuentra en la fase de establecimiento, y que el mecanismo de gobernanza y la junta directiva aún se están construyendo.

En otras palabras, esta acción no anuncia principalmente que "el producto está maduro", sino más bien que "queremos darle a este protocolo un hogar neutral".

La implicación subyacente es bastante simple.

Si x402 continúa pareciendo una característica de producto de Coinbase (como la actual Base), entonces los proveedores de servicios en la nube, las empresas de pago, las organizaciones de tarjetas y los actores de la plataforma, incluso si están técnicamente dispuestos a adoptarlo, dudarán por motivos políticos.

Nadie quiere confiar la futura capa de acceso de pago a una sola plataforma. El hecho de que esté bajo la tutela de la Linux Foundation no se debe a que Coinbase no quiera controlarlo, sino precisamente a que desea que x402 sea ampliamente adoptado, por lo que primero debe eliminar la carga de "este es el protocolo de Coinbase".

Este punto es realmente muy importante porque mucha gente considera que acciones como las de la fundación son meros gestos de relaciones públicas o de código abierto.

Pero en la guerra de protocolos, la gobernanza forma parte del producto.

Especialmente cuando un estándar aún está en sus primeras etapas y carece de efectos de red absolutos, la llamada "neutralidad y confiabilidad" es tan importante como la elegancia técnica.

Por el contrario, si x402 llega a convertirse en el futuro en una especie de acceso de pago nativo HTTP, probablemente no sea porque su código sea el más elegante, sino porque ha reducido los costes políticos antes que otras soluciones.

En otras palabras, la gobernanza en este caso no desempeña un papel de apoyo; la gobernanza en sí misma es un motor de crecimiento.

2. ¿Qué pretende realmente Stripe con su doble estrategia?

El jugador al que hay que prestar atención esta vez es sin duda Stripe, ya que sus acciones son las más desconcertantes.

Por un lado, el 18 de marzo lanzó MPP con gran bombo y platillo, presentándolo como un estándar abierto para pagos en máquinas expendedoras.

Por otro lado, es uno de los contribuyentes fundadores de la Fundación x402 y su propia documentación también admite pagos mediante máquinas x402.

La documentación de Cloudflare es aún más directa, al afirmar explícitamente que MPP es compatible con versiones anteriores del proceso de pago principal de x402, y que los clientes de MPP pueden consumir directamente los servicios x402 existentes.

Si se analiza únicamente desde la perspectiva de la "competencia de protocolos", Stripe parece estar empleando una estrategia doble.

Pero si se amplía un poco la perspectiva, este enfoque resulta ser el más sensato desde el punto de vista comercial.

Porque lo que Stripe realmente quiere proteger no es solo el protocolo de enlace 402 en sí.

Lo que realmente pretende proteger son las capas superiores al simple acuerdo de colaboración: credenciales, cumplimiento normativo, riesgos, informes, impuestos, reembolsos e integración de comercios.

Stripe no parece creer firmemente en ningún protocolo en particular; más bien, parece estar asegurándose de que, independientemente del estándar de autenticación que finalmente prevalezca, Stripe siga siendo la capa de abstracción predeterminada para los pagos de agentes.

Apoyar x402 garantiza la participación en el ecosistema abierto; impulsar MPP ayuda a definir la semántica subyacente; y promover aún más ACP y los tokens de pago compartidos salvaguarda la capa de valor más sólida de los flujos de trabajo y las credenciales de pago.

Por lo tanto, el aspecto más "extraño" de Stripe en esta ocasión es, en realidad, su aspecto más honesto.

No pretende que el futuro se reduzca rápidamente a un único protocolo. Se trata de tomar medidas para decirles: al menos en esta etapa, nadie debería apostar por un solo bando.

3. En realidad, se trata de una historia sobre infraestructura B2B.

Cada vez tengo más la sensación de que muchos medios de comunicación han desviado la atención de este asunto.

Cuando se trata de pagos a agentes, lo más fácil es pensar en el comercio minorista: La IA te ayuda a reservar vuelos, hoteles, realizar pedidos y completar el proceso de pago.

Pero si analizamos los escenarios que se han implementado públicamente y que realmente tienen un componente de infraestructura, el primero en despegar no es el pago en tiendas minoristas, sino más bien el acceso de pago B2B, más común y real: API de pago, datos de pago, herramientas de pago, sesiones de navegador de pago, flujos de trabajo de agentes de pago.

Cloudflare ahora admite abiertamente el cobro por contenido HTTP, API y herramientas MCP mediante x402 y MPP.

La vía de adopción más sólida para x402 reside en las API y herramientas de pago entre desarrolladores, porque el modelo "sin cuenta + pago por solicitud" no es solo un truco publicitario, sino una realidad operativa genuina.

Los cambios que esto conlleva son bastante significativos.

En el pasado, cobrar por una API generalmente requería pasar por una serie de procesos "fáciles de usar para el usuario": abrir una cuenta, vincular la facturación, emitir claves de API, establecer límites, conciliar y luego gestionar los permisos de pago.

Para los humanos, esto ya resulta bastante molesto; para los agentes, es aún más incómodo.

El aspecto más atractivo de x402 no es que sea más criptográfico o que incorpore más inteligencia artificial, sino que intenta reinsertar el "acceso de pago" en el propio protocolo HTTP, permitiendo que el control de acceso y la negociación de pagos se produzcan como en una solicitud-respuesta normal.

El servidor devuelve un código 402, indicando el coste de la solicitud; el cliente paga y vuelve a intentar la misma solicitud con las credenciales de pago.

Si se analiza este modelo desde la perspectiva del software B2B y el acceso máquina a máquina, su funcionamiento es mucho más fluido que desde la perspectiva del comercio minorista.

Además, cuanto más se analiza el sector B2B, más evidentes se vuelven las ventajas de x402 y menos graves sus deficiencias.

Porque en el comercio de consumo, los reembolsos, las devoluciones de cargo, el comerciante registrado, la protección del consumidor y la atribución de responsabilidad son cuestiones complejas; pero en las llamadas a API y herramientas B2B, la importancia de estas cuestiones disminuye significativamente.

Por el contrario, la demanda de "sin cuenta, pago por llamada, obtener resultados y listo" es muy real.

El sector minorista es, sin duda, más grande, más dinámico y más fácil de captar la atención; pero los escenarios que realmente definen cómo es el protocolo a menudo no son los más dinámicos, sino aquellos que primero exponen necesidades reales.

En el contexto actual de pagos a agentes, es probable que ese escenario no sea el carrito de compras, sino el creciente número de accesos de pago entre software, agentes y flujos de trabajo.

4. El desarrollo de la industria valida mi juicio previo sobre la interoperabilidad.

El argumento central de mi último artículo fue la interoperabilidad.

En aquel momento, este juicio sonaba algo así como "debería estructurarse de esta manera".

Ahora, se asemeja cada vez más a una limitación de la realidad, ya que el mercado abierto ya está demostrando su postura con los pies.

Cloudflare no se decantó por ninguna de las partes, sino que ofrece soporte directo tanto para x402 como para MPP, al tiempo que establece claramente las asignaciones de compatibilidad.

Google participa en x402 al tiempo que continúa impulsando AP2 y UCP.

Visa y Mastercard tampoco han expresado sus estrategias como una solución "todo en uno"; en cambio, ambas se están uniendo a x402 mientras continúan redoblando sus esfuerzos en tokens de agente, verificación de identidad, validación de instrucciones y señales de disputa.

Las apuestas multilaterales de los gigantes son decisiones racionales, no hipocresía comercial.

¿Por qué ocurre esto? Porque estos protocolos ni siquiera están en la misma capa.

Hasta el momento, x402 y MPP están más cerca de la capa de protocolo de enlace HTTP de pago, abordando la cuestión de "cómo garantizar que las solicitudes devuelvan la capacidad de pago".

AP2 se acerca más a la autorización y la intención de confianza, abordando la pregunta de "¿tiene este agente derecho a gastar este dinero?".

UCP y ACP se asemejan más a la capa de flujo de trabajo, ya que se ocupan del descubrimiento, el proceso de pago, las relaciones con los comerciantes y la transmisión de credenciales; cuestiones que se acercan más a "quién controla el tráfico y la orquestación de las transacciones".

Muchas empresas que admiten simultáneamente x402, MPP, AP2 y UCP no lo hacen porque los propios protocolos no estén claros, sino porque la arquitectura que finalmente prevalezca probablemente abarcará múltiples capas e incluso puede requerir que varios protocolos se combinen.

Así pues, si tuviera que resumir mi juicio anterior en una sola frase, ahora creo aún con más firmeza que, sin interoperabilidad, esta ola de ecología no habría surgido en absoluto.

Viéndolo ahora, el mercado está validando activamente este juicio.

Además, este criterio también es importante para la comparación entre el sector B2B y el minorista.

Porque en el mundo del comercio minorista, es posible que acabe siendo absorbido por unas pocas plataformas grandes y unos pocos flujos de trabajo importantes; pero el mundo B2B no es así.

Las empresas existen inherentemente en una realidad donde coexisten la multi-nube, múltiples métodos de pago, múltiples sistemas de flujo de trabajo y múltiples sistemas de permisos de identidad.

Cualquiera que intente utilizar un nuevo protocolo para renovar por completo toda la infraestructura empresarial probablemente fracasará primero.

Lo que los clientes B2B están realmente dispuestos a pagar no suele ser "el protocolo correcto", sino la capacidad de hacer que los sistemas existentes funcionen en un entorno multiprotocolo.

Esta lógica explica precisamente por qué la interoperabilidad es más importante en entornos empresariales que en entornos de consumo.

5. Esto no es simplemente una competencia de protocolos, sino una competencia de pilas de capas.

Una vez que comprenda este asunto como una estructura en capas, muchos fenómenos que originalmente parecían caóticos cobrarán sentido de inmediato.

En la capa inferior se encuentra el protocolo de acceso de pago.

Esta capa se refiere a cómo las solicitudes HTTP expresan "aquí se requiere el pago" y cómo el cliente recupera las credenciales de pago después de efectuar el pago.

En este aspecto, x402 y MPP son los principales competidores. MPP está intentando formalizar el error 402 dentro de una semántica de autenticación HTTP más oficial; mientras que x402 se centra más en convertir el error 402 en una plataforma, utilizando encabezados personalizados, facilitadores, abstracciones de liquidación en la cadena de bloques e integración con el ecosistema para ponerlo en funcionamiento primero.

Una se asemeja más a una ruta semántica estandarizada, mientras que la otra se parece a una ruta de distribución de plataforma.

El siguiente nivel es la autoridad para gastar, que es "quién autorizó este dinero".

Esta capa es la clave que mucha gente aún no ha comprendido del todo.

Que las máquinas paguen dinero no es tan difícil; el verdadero desafío radica en garantizar que se pueda confiar en que las máquinas estén autorizadas para gastar dinero.

AP2 es importante precisamente porque aborda no solo "cómo pagar", sino también los requisitos, las credenciales verificables, la autenticidad y la rendición de cuentas.

Los tokens de agente, la validación de instrucciones, las claves de acceso y las señales de disputa en las que Visa y Mastercard han reforzado recientemente sus esfuerzos, en esencia, se engloban dentro de esta capa.

El siguiente nivel es el flujo de trabajo y la distribución.

Esto incluye el descubrimiento, el proceso de pago, las relaciones con los comerciantes, el intercambio de credenciales y la integración de la IA en la superficie; cuestiones que se asemejan más a "quién controla el tráfico y la orquestación de las transacciones".

UCP y ACP son más bien competidores por esta capa.

Para el sector B2B, esta capa puede no ser tan dinámica a corto plazo, pero su valor a largo plazo podría ser muy alto.

Porque si en el futuro cada vez más software empresarial es coordinado, solicitado, adquirido y pagado por agentes, entonces quien domine el lenguaje del flujo de trabajo no solo gestionará un único pago, sino todo el flujo de trabajo.

Una vez que se separan estas tres capas, se descubre un hecho muy simple: no es necesario esperar que un solo protocolo cubra todos los problemas.

Una vía más realista sería que estas tres capas se desarrollaran por separado y luego interoperaran gradualmente.

Por esta razón, apostar a múltiples opciones no es indecisión, sino racionalidad.

6. El verdadero riesgo de x402 puede no ser la regulación, sino la economía de la concurrencia.

Si solo reconocemos "la coexistencia de múltiples protocolos", todavía no es suficiente.

El mayor riesgo para x402 puede que no sea principalmente la regulación, sino más bien la economía del momento de la verificación/momento de uso que conlleva el proceso de verificación y liquidación en dos pasos.

En pocas palabras, si la verificación del pago y la liquidación final no son lo mismo, entonces en entornos reales de internet caracterizados por una alta concurrencia, reintentos, capas de proxy y capas de almacenamiento en caché, habrá una oportunidad para "pagar una vez, acceder varias veces".

El ecosistema x402 también está corrigiendo actualmente fallos como la caché de liquidación, la extensión de idempotencia y el identificador de pago, lo que indica precisamente que el problema no es meramente teórico.

¿Por qué es esto especialmente relevante para los lectores del sector B2B?

Porque lo que más teme el mundo B2B no es la incapacidad de producir una demostración impecable, sino que haya demasiados casos excepcionales y que, una vez que entre en producción, empiecen a surgir problemas.

La monetización de las API puede parecer superficialmente como pagar unos pocos centavos por solicitud, lo cual es bastante poco; pero una vez que su producto cobra por llamada, por resultado o por flujo de trabajo, entonces si "pague una vez y obtenga uno" o "pague una vez y obtenga muchos" no es solo un detalle del producto, sino una cuestión de vida o muerte.

Por lo tanto, si x402 realmente puede despegar en el sector B2B, un requisito previo importante no es la narrativa, sino que estos mecanismos de seguridad por defecto deben ser lo suficientemente sencillos; de lo contrario, las empresas no se sentirán seguras al atraer tráfico real.

7. Los protocolos pueden ser gratuitos, pero las cabinas de peaje no desaparecerán.

Hay un punto más que creo que merece la pena desarrollar en este artículo.

Muchos protocolos abiertos acaban llegando a un punto muy conocido: el protocolo en sí se vuelve cada vez más barato, incluso gratuito, pero a la par irán surgiendo verdaderas barreras de acceso.

x402 no es diferente.

Si bien la norma en sí misma hace hincapié en la apertura, la neutralidad y la ausencia de comisiones, esto no significa que la captura de valor vaya a desaparecer.

Si x402 tiene éxito, el valor no permanecerá principalmente dentro del protocolo, sino que migrará a facilitadores, monederos, gestión de claves, descubrimiento, motores de políticas y envoltorios de confianza: estas capas adyacentes.

Esto es especialmente importante para las relaciones B2B.

Dado que los clientes empresariales no van a reformar por completo sus sistemas para adoptar un nuevo protocolo, lo que realmente están dispuestos a pagar es por quién puede ayudarles a optimizar la orquestación, las políticas, los riesgos, el cumplimiento normativo, la auditoría, la liquidación y los límites de permisos en un entorno multiprotocolo.

En otras palabras, los protocolos se parecerán cada vez más a los lenguajes subyacentes, pero la capacidad de traducir estos lenguajes a funcionalidades "listas para la empresa" se convertirá más fácilmente en nuevas plataformas y nuevos puntos de acceso.

Por eso también creo que, al analizar x402 hoy en día, no deberíamos centrarnos únicamente en cuál de los dos, Coinbase, Cloudflare o Stripe, se parece más al "protagonista".

Lo que realmente merece la pena observar es quién tiene la mejor oportunidad de posicionarse en estas capas adyacentes.

Cloudflare tiene una posición en la distribución de tráfico y en el borde de la red, Stripe tiene una posición en la infraestructura de pagos y las relaciones con los comerciantes, Visa y Mastercard tienen posiciones en credenciales, tokens de red y confianza del consumidor, y Google tiene una posición en flujos de trabajo y superficies de descubrimiento.

Puede que la verdadera obtención de valor no se produzca en "quién definió la Sección 402", sino más bien en "quién integró la Sección 402 en sistemas empresariales más amplios".

8. Conclusión

La Fundación x402 no está anunciando que x402 ya haya ganado en todos los protocolos de comercio basados ​​en agentes.

Se reconoce públicamente que esta generación de pagos a agentes no se regirá por un protocolo único desde el primer día.

El hecho de que Coinbase haya cedido x402 a la Linux Foundation tiene como objetivo convertirlo en una capa pública neutral en lugar de un producto exclusivo.

Que Stripe impulse MPP al tiempo que se une a x402 no es indecisión; es porque sabe que no se debe apostar por un solo bando en este momento.

Cloudflare admite ambos sistemas simultáneamente porque es lo más parecido al tráfico real.

Las acciones de empresas como Google, Visa, Mastercard y Adyen también indican lo mismo: primero, dejar que los sistemas interoperan y luego debatir quién ocupará finalmente qué capa.

Y si cambiamos nuestra perspectiva y dejamos de centrarnos en el comercio minorista, esta conclusión se vuelve aún más clara.

Porque los primeros en necesitar estos protocolos quizás no sean los carritos de compra, sino más bien el creciente número de software y servicios B2B que cobran por llamada, tarea o resultado.

Sin duda, el sector minorista es más grande, pero el sector B2B a menudo revela las necesidades reales con mayor antelación y define cómo será finalmente la infraestructura.

En mi último artículo, puse la interoperabilidad en el centro de la conversación, y creo que la respuesta del mercado ahora es bastante clara: sí, e incluso antes de lo que pensaba en aquel momento.

En este sentido, la Fundación x402 no es el final de esta historia.

Simplemente nos permite ver con antelación que el verdadero tema nunca ha sido "quién ganará", sino más bien "este mundo está destinado a interoperar primero, y quién puede ocupar la capa más valiosa después de la interoperabilidad".