La trampa de confianza de los protocolos abiertos: ¿por qué necesita x402 una capa de responsabilidad centralizada?

El protocolo de pago x402 revela 31 nuevas vulnerabilidades, con un 99% de las transacciones enfrentando el riesgo de robo de activos.

Escrito por: @Jun__Yoo

Compilado por: AididiaoJP, Foresight News

Akiba de CryptoSlate (@akibablade) publicó recientemente un artículo titulado "Las 31 vulnerabilidades recién descubiertas ponen en riesgo el robo de activos y las compras gratuitas del 99% de los pagos criptográficos x402".

Este artículo se basa en un trabajo titulado "Cuando HTTP 402 se encuentra con la blockchain: los riesgos del emergente pago x402". Este trabajo ha sido aceptado y se publicará en la conferencia USENIX Security 2026.

El documento se centra en cómo x402 delega la verificación de pruebas de pago y la liquidación en cadena a un facilitador de terceros. Este diseño concentra la lógica de confianza y verificación en una infraestructura de pago compartida por múltiples comerciantes independientes. Si un facilitador presenta una vulnerabilidad, puede afectar a numerosos servicios.

Los investigadores también definieron ocho reglas de seguridad que los facilitadores deben seguir. La violación de estas reglas puede dar lugar a cuatro tipos de ataques: compras gratuitas, robo de activos, denegación de servicio y abuso de Gas. Evaluaron a 15 facilitadores principales y encontraron 49 violaciones de reglas y 31 vulnerabilidades previamente desconocidas. Los resultados se han divulgado en privado a las partes operativas relevantes. Algunos problemas ya han sido solucionados, mientras que otros están en proceso de reparación.

El motivo por el cual esta investigación pudo llevarse a cabo es que x402 fue desarrollado como un protocolo abierto desde el principio. Las especificaciones del protocolo y el SDK de referencia son públicos, lo que permitió a los investigadores deducir las reglas de seguridad del proceso de pago. Utilizaron un SDK de código abierto y comerciantes de prueba que construyeron ellos mismos para completar la investigación.

El código abierto no elimina las vulnerabilidades, pero proporciona un camino para que los defectos descubiertos externamente se conviertan en estándares de seguridad compartidos. El protocolo x402 fue entregado a la Fundación Linux el 2 de abril, y la Fundación x402 comenzó oficialmente a operar el 14 de julio, con 40 miembros. Esto proporciona un foro oficial para discutir los resultados de las investigaciones a nivel de especificaciones e implementaciones de referencia, en lugar de depender únicamente de los parches de un solo proveedor.

Los investigadores también lanzaron una versión pública de x402scope, que ha eliminado el código de explotación sensible. Están en conversaciones con Coinbase y otros participantes importantes del ecosistema sobre cómo integrar su verificación de reglas en el proceso de validación antes del desarrollo y despliegue.

La discusión sobre la madurez del protocolo termina aquí. Quiero plantear una pregunta más fundamental a partir de estos hallazgos.

En lugar de centralizar x402 en sí, ¿necesita un protocolo abierto una capa de responsabilidad centralizada para hacer cumplir los estándares de verificación y asumir los costos y pérdidas de liquidación derivados de eventos de seguridad?

La centralización no equivale automáticamente a seguridad. Pero en el ámbito de los pagos, la parte que ejerce el poder también debería asumir el costo del fracaso.

Veamos cómo funciona realmente x402. Cualquiera puede operar un servidor o convertirse en facilitador. Pero el sistema no es completamente sin confianza. El documento también define al facilitador como "un intermediario que asume la confianza". Una vez que la verificación y la liquidación se delegan, los usuarios deben confiar en el facilitador en un grado considerable.

El problema es que la confianza se concentra, pero el protocolo no exige el capital correspondiente, mecanismos de responsabilidad o certeza de pago. Esta brecha se refleja en tres partes del diseño.

Primero, la verificación se parece más a predecir "la liquidación sigue siendo viable en este momento", en lugar de como la autorización de una tarjeta de crédito. Verifica firmas, saldos, nonce y tiempos de expiración, pero no bloquea fondos ni consume nonce.

En segundo lugar, la separación de verify → lógica de negocio → settle (liquidación) tiene la intención de proteger a los consumidores y comerciantes. El protocolo no tiene un mecanismo para vincular la verificación y la liquidación a través de un estado compartido. Si un comerciante actúa basándose en el resultado de verificación del facilitador y la liquidación posterior falla, el comerciante asume toda la pérdida.

En tercer lugar, muchos facilitadores subsidiarán los costos de liquidación en cadena. Los atacantes pueden manipular el camino de ejecución, haciendo que el facilitador pague los costos de Gas resultantes. En Solana, los atacantes incluso pueden inducir al facilitador a pagar el alquiler de cuentas controladas por el atacante.

Los pagos con tarjeta de crédito también separan la autorización y el cargo. La diferencia es que el emisor reserva parte del límite de crédito o fondos del titular de la tarjeta durante la autorización. Las reglas de la red luego proporcionan cierto grado de certeza de pago al comerciante. Si hay un problema, hay opciones de revocación de autorización, disputas y procedimientos de manejo de controversias disponibles.

x402 no tiene un emisor que bloquee fondos y garantice el pago. Por lo tanto, el servidor verifica la viabilidad del pago, ejecuta la lógica de negocio y luego llama a la liquidación. El problema es que los extremos no comparten estado. Después de la verificación, el saldo, nonce o tiempo de validez pueden cambiar. Si el servidor realiza una operación irreversible antes de la liquidación, el comerciante puede sufrir pérdidas. Si el facilitador envía una transacción manipulada, puede perder Gas o activos que controla.

Las redes de tarjetas asumen este costo de confianza a través del capital del emisor y equipos de gestión de riesgos, y luego recuperan el costo a través de tarifas. x402 eliminó ese rol, pero no eliminó el costo.

Por lo tanto, ¿es necesario establecer una capa de responsabilidad sobre el protocolo abierto?

Esta centralización no significa entregar todo el protocolo x402 a un solo operador. Cada ruta de pago debe tener un responsable claramente definido. Varios operadores aún pueden competir bajo el mismo estándar abierto, y los usuarios pueden cambiar de facilitador. Esta estructura concentra la responsabilidad operativa mientras mantiene la apertura del protocolo y la competencia entre proveedores.

La puerta de monetización de Cloudflare es un posible ejemplo. Mantiene el formato de pago programable de x402, mientras que maneja las políticas de pago, verificación y control de acceso en una capa de control única. Otra ruta es utilizar facilitadores especializados que ofrezcan acuerdos de nivel de servicio, límites de Gas, verificación previa a la liquidación y respuesta a eventos.

ERC-8004 y los sistemas de reputación parecen ofrecer alternativas. Pero la reputación es solo una señal adicional para evaluar riesgos; no reserva fondos ni proporciona garantías de pago. Creo que la reputación por sí sola no puede llenar la brecha de responsabilidad.

Esta perspectiva también requiere una revisión del papel y la estructura de la capa de descubrimiento. Esta capa puede ir más allá de simplemente enumerar los servicios disponibles, convirtiéndose en una capa de confianza y enrutamiento que filtra qué recursos y facilitadores cumplen con los estándares de seguridad establecidos. Si se necesita una garantía de pago, puede distinguir claramente entre los operadores centralizados que proporcionan garantías y las rutas de pago. Desde esta perspectiva, hay dos jugadores clave que merecen atención:

La estrategia de integración de CDP (@CoinbaseDev) combina Agentic Wallet, CDP Facilitator y Bazaar, proporcionando funciones de billetera, pago, cumplimiento y descubrimiento en una única pila tecnológica.

La estrategia de integración de Orthogonal (@orthogonal_sh) unifica el descubrimiento de servicios, el pool de claves API, la estandarización de respuestas y la facturación bajo una cuenta, un saldo y una factura. Soporta créditos, x402 y MPP. Esto coloca la complejidad de gestionar múltiples proveedores y métodos de pago bajo una puerta de enlace central.

Estas estrategias aún no ofrecen garantías de pago o absorción de pérdidas. Pero colocan las funciones fragmentadas de billetera, verificación, facturación y descubrimiento bajo un único operador, proporcionando una base para una capa de responsabilidad centralizada.

Si la capa de responsabilidad centralizada se vuelve común, la estructura de pago en sí misma también podría cambiar. Un modelo posible es reemplazar verify → lógica de negocio → settle por verify → settle → lógica de negocio.

El orden actual protege al consumidor, siempre que la liquidación sea irreversible. Una vez que el operador asuma la responsabilidad de reembolsos y manejo de disputas, esta suposición cambiará. Se puede confirmar primero la liquidación, eliminando el riesgo de impago para el comerciante. Si la ejecución posterior falla, el operador puede reembolsar al consumidor. El operador deberá asumir la necesidad de liquidez y la obligación de liquidación antes de la liquidación final, lo que hace que su estructura de capital y responsabilidad sea aún más importante.

Este modelo no sigue el proceso de liquidación por transacción actual de x402. x402 continuará como una interfaz abierta para comunicar los términos de pago y los datos de autorización. Los operadores agregarán el flujo de fondos real y completarán la liquidación final en la cadena. Los registros de pagos individuales se mantendrán en el libro mayor interno del operador, mientras que la blockchain registrará la liquidación final agregada. Dado que el libro mayor interno es reversible, esta estructura reduce el problema de los pagos irreversibles. El operador también puede manejar reembolsos y disputas como un emisor de tarjetas.

Alguien podría preguntar:

¿No es esto simplemente tratar la blockchain como una base de datos de pagos compartida?

Sí.

Más precisamente, la blockchain se convertirá en un libro mayor de liquidación compartido que registra los saldos finales entre los operadores. Los pagos individuales se mantendrán fuera de la cadena. Al menos en este mercado, desempeñar este papel de manera confiable puede ser suficiente. El sistema aún puede aprovechar los bajos costos de liquidación y las ventajas de las monedas programables.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.