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

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

Escrito por: @Jun__Yoo

Traducido por: AididiaoJP, Foresight News

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

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 trabajo 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. Una vez que un facilitador presenta una vulnerabilidad, puede afectar a una gran cantidad de 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 de manera privada a las partes operativas relevantes. Algunos problemas ya han sido solucionados, mientras que otros están en proceso de reparación.

La razón por la que se pudo llevar a cabo esta investigación es que x402 se desarrolló desde el principio como un protocolo abierto. Sus especificaciones y 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 crearon sus propios comerciantes de prueba 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 transferido 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 hallazgos a nivel de especificaciones e implementaciones de referencia, en lugar de limitarse a 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 principales del ecosistema sobre cómo integrar su verificación de reglas en el proceso de validación previo al 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 trabajo 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 está centralizada, 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 asemeja más a predecir "que la liquidación aún es 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 como objetivo 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 en función del resultado de la verificación del facilitador y la liquidación posterior falla, el comerciante asume toda la pérdida.

En tercer lugar, muchos facilitadores subsidian los costos de liquidación en cadena. Los atacantes pueden manipular la ruta 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 crédito o fondos del titular de la tarjeta en el momento de la autorización. Las reglas de la red luego proporcionan un cierto grado de certeza de pago al comerciante. Si hay un problema, hay opciones de revocación de autorización, contracargos, sanciones al comerciante y procedimientos de resolución de disputas 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 settle. El problema es que los extremos no comparten estado. Después de la verificación, el saldo, nonce o fecha de vencimiento 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 lo recuperan 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?

Aquí, la 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, al tiempo que mantiene la apertura del protocolo y la competencia entre proveedores.

El Monetization Gateway 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 única capa de control. Otra opción 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 reevaluación del papel y la estructura de la capa de descubrimiento. Esta capa puede ir más allá de simplemente listar servicios disponibles, convirtiéndose en una capa de confianza y enrutamiento, filtrando 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, ofreciendo 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 grupo 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 en 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 solo operador, proporcionando una base para una capa de responsabilidad centralizada.

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

El orden actual protege a los consumidores, siempre que la liquidación sea irreversible. Una vez que el operador asume la responsabilidad de reembolsos y 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 debe asumir la necesidad de liquidez y la obligación de liquidación antes de la liquidación final, lo que hace que su capital y estructura de responsabilidad sean aún más importantes.

Este modelo no sigue el proceso de liquidación por transacción actual de x402. x402 continuará como una interfaz abierta para comunicar términos de pago y 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 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, tradear 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.