El XRP Ledger tiene un límite máximo de 100 mil millones de XRP. Durante aproximadamente once años, ese límite fue solo una sugerencia. El 9 de octubre de 2026, la Fundación XRPL publicó un informe de divulgación que confirmaba que una sola transacción manipulada podría haber creado alrededor de 18,4 billones de XRP gastables, unas 184 veces el suministro total, y que el código que lo permitía había estado en el motor de pagos desde noviembre de 2015. El error fue encontrado por un agente de IA, parcheado en tres días y distribuido de una forma que el ledger nunca había utilizado antes. Nadie lo explotó. Esa es la buena noticia. Todo lo demás de la historia merece un análisis más detenido.
Qué hacía realmente el error de desbordamiento del XRP Ledger
El fallo estaba en la parte del motor de pagos que gestiona un pago que cruza un libro de órdenes. Cuando un pago consume muchas ofertas a la vez, el motor suma las cantidades que debe a cada propietario de oferta. Esa suma utilizaba enteros con signo de 64 bits sin ninguna comprobación de desbordamiento. Si el total supera 2 elevado a la 64, el contador se desborda y vuelve a un número pequeño, como cuando el cuentakilómetros de un coche pasa de 999999 a 000000.
Aquí está la parte fea. El motor cobraba al comprador el total desbordado, que era minúsculo. Pagaba a cada propietario de oferta su cantidad completa, sin desbordar. La diferencia entre esos dos números son XRP que no existían un momento antes.
El ledger sí tiene una red de seguridad para exactamente esto. Una comprobación de invariante llamada XRPNotCreated se ejecuta después de cada transacción y se niega a validar cualquier cosa que aumente el total de XRP. El problema es que el invariante rastreaba el cambio neto de XRP usando la misma aritmética de 64 bits sin comprobación. Un crédito lo suficientemente grande desbordaba también el contador del invariante, así que una transacción que imprimía billones de XRP parecía, para la comprobación de seguridad, una quema de comisión rutinaria. Dos errores independientes, escritos con dos años de diferencia, anularon la protección del otro.
Cómo 256 ofertas suman 18 billones de XRP
Veria Labs, la empresa de seguridad cuyo agente de IA encontró el error, publicó la aritmética. El ataque utilizaba 256 ofertas. Cada oferta se vendía por 2 elevado a la 56, más un drop de XRP. Multiplica 256 por esa cifra y el total llega exactamente a 2 elevado a la 64, más 256 drops. El drop extra por oferta importa: sin él, la suma se desborda a exactamente cero, lo que el motor rechazaría como un pago en seco. Con él, al comprador se le cobran 256 drops, unos 0,000256 XRP, mientras que los 256 propietarios de ofertas reciben colectivamente 2 elevado a la 64 drops. Eso son 18.446.744.073.709.551.616 drops, o aproximadamente 18,45 billones de XRP.
El atacante necesitaba 256 cuentas financiadas porque cada cuenta XRPL está limitada a 100 mil millones de XRP, muy por debajo de la cantidad por oferta dividida entre una sola cuenta. También necesitaba unos cientos de XRP en reservas y comisiones de transacción, todo recuperable. No se requería acceso a validadores. El ataque podía repetirse con cuentas nuevas. Veria cifró el valor en riesgo en aproximadamente 94.000 millones de dólares, más de sesenta veces el robo de Bybit de 1.500 millones de dólares que actualmente ostenta el récord de un hackeo cripto que realmente ocurrió.
| Ingrediente | Valor | Por qué importa |
|---|---|---|
| Ofertas consumidas en un pago | 256 | Por debajo del límite de 1.000 ofertas por recorrido de libro |
| Precio por oferta | 2^56 + 1 drops | Se mantiene por debajo del límite de 100 mil millones de XRP por cuenta |
| Total que calculó el motor | 2^64 + 256 drops | Se desborda a 256 drops en aritmética de 64 bits |
| Lo que pagó el comprador | 256 drops (0,000256 XRP) | El valor desbordado |
| Lo que recibieron los vendedores | Unos 18,45 billones de XRP | El valor sin desbordar, 184 veces el suministro total |
| Coste para el atacante | Unos cientos de XRP, recuperables | Reservas más comisiones |
| Acceso a validadores necesario | Ninguno | Cualquier cuenta financiada podía hacerlo |
Un agente de IA lo encontró un lunes por la noche
El informador oficial es Cayden Liao de Veria Labs, con el agente de IA de la empresa acreditado junto a él. Según el propio relato de Veria, el agente fue apuntado al código base de rippled el 21 de septiembre, marcó ambos desbordamientos, dedujo que podían encadenarse y produjo una prueba de concepto funcional en una red local. Despertaron a un ingeniero fundador a las 4 de la mañana para comprobarlo. Para la mañana del 22 de septiembre, el equipo tenía la confianza suficiente para presentarlo a través del programa de recompensas por errores de XRPL, calificándolo como Mayor. RippleX lo reprodujo ese mismo día y lo elevó a Crítico. Realistamente, Veria afirma que agentes de programación de propósito general apuntados al mismo código después de la divulgación no lograron encontrarlo. Tómalo con la cautela habitual de una empresa que vende la herramienta que lo hizo. El punto más amplio se mantiene independientemente. El código de agregación BookStep data de noviembre de 2015 y el invariante XRPNotCreated de febrero de 2017. El XRPL ha pagado más de 1 millón de dólares en recompensas y ha realizado más de una docena de auditorías y concursos de auditoría desde 2024. Humanos y empresas de auditoría miraron este código durante una década y lo pasaron por alto. El patrón se está volviendo familiar. Coldcard perdió aproximadamente 1.367 BTC este verano por un error de firmware de cinco años que su fabricante sospecha que fue encontrado con ayuda de IA. El código antiguo ya no es seguro solo porque sea antiguo.
Por qué la solución se saltó la votación de validadores
Aquí es donde la historia deja de ser una victoria de seguridad limpia y se convierte en un debate de gobernanza. El XRP Ledger normalmente cambia las reglas de transacción mediante enmiendas. Una nueva regla se distribuye en el software desactivada, los validadores votan sobre ella y solo se activa tras mantener más del 80 por ciento de apoyo en la Lista de Nodos Únicos predeterminada durante dos semanas consecutivas. El sistema lleva más de una década en funcionamiento y nunca se ha eludido deliberadamente para un cambio en el procesamiento de transacciones.
Hasta el 25 de septiembre. La solución del desbordamiento se distribuyó directamente en xrpld 3.4.1 sin puerta de enmienda. Entró en vigor en cada servidor en el momento en que ese servidor se actualizó. El razonamiento de la Fundación XRPL es directo: una votación de enmienda habría publicado la solución, y por tanto el error, durante dos semanas antes de entrar en vigor. Cualquiera que leyera el diff habría tenido una quincena para imprimir 18 billones de XRP. La Fundación dice que la decisión fue tomada conjuntamente por ella misma, RippleX, los desarrolladores principales y los validadores, y que ninguna parte podría haber tomado la decisión por sí sola.
El enfoque conllevaba su propio riesgo, que el informe de divulgación admite. Si alguien hubiera intentado el exploit mientras la red estaba dividida entre servidores parcheados y sin parchear, los dos grupos habrían discrepado sobre el estado del ledger. En el peor de los casos, la red se detiene. El equipo juzgó que una posible detención era preferible a una explosión de suministro segura, algo difícil de discutir. Más del 80 por ciento de los validadores de la UNL predeterminada ejecutaban la 3.4.1 horas después de su lanzamiento el 25 de septiembre.
| Fecha | Evento |
|---|---|
| Nov 2015 | Se escribe el código de suma de ofertas de BookStep con adición de 64 bits sin comprobación |
| Feb 2017 | Se añade el invariante XRPNotCreated, usando la misma aritmética sin comprobación |
| 21 Sep 2026 | El agente de IA de Veria Labs marca ambos desbordamientos y los encadena |
| 22 Sep 2026 | Se reporta a través del Bug Bounty de XRPL, RippleX lo reproduce, se eleva a Crítico |
| 23 Sep 2026 | La solución se fusiona de forma privada en el candidato de lanzamiento 3.4.1 |
| 25 Sep 2026 | Se lanza xrpld 3.4.1, más del 80 por ciento de los validadores de la UNL predeterminada actualizados |
| 8 Oct 2026 | Veria Labs recibe la recompensa máxima de 250.000 dólares |
| 9 Oct 2026 | Se publica el informe de divulgación pública, se activa la enmienda Batch fix |
| 12 Oct 2026 | ZachXBT califica públicamente la recompensa como demasiado baja |
La lucha por la descentralización que siguió
En resumen, Justin Bons de Cyber Capital, un crítico de XRP desde hace mucho tiempo, usó el episodio para argumentar que comercializar XRP al por menor como descentralizado equivale a fraude. Sus quejas concretas: el lanzamiento del 25 de septiembre se distribuyó solo como binarios compilados, con el código fuente retenido temporalmente, y se presionó a los operadores para que actualizaran un binario que no podían inspeccionar. El informe de divulgación de XRPL confirma que la fuente se publicó después, aunque no dice cuándo.
En la práctica, el contraargumento vino tanto de operadores de validadores independientes como de la Fundación. XRP Kuwait, que ejecuta su propio nodo, lo expresó así: coordinar no es lo mismo que controlar. Los operadores independientes leyeron el mismo aviso, llegaron a la misma conclusión y actualizaron. Nadie les obligó. Bitcoin ha hecho lo mismo, notablemente con el error de inflación de 2018 en Bitcoin Core 0.16.x, cuando los desarrolladores distribuyeron silenciosamente una solución antes de explicar qué solucionaba. Toda cadena con un error grave acaba enfrentándose a la elección entre transparencia y supervivencia, y todas han elegido la supervivencia. Al final del día, donde Bons tiene razón es en los binarios. Distribuir un binario no verificable y pedir a los validadores que lo ejecuten de inmediato es un ejercicio de confianza, por muy justificado que esté. La versión honesta de la posición de XRPL es que su conjunto de validadores confió lo suficiente en la Fundación y RippleX como para ejecutar código no revisado durante unos días. Si llamas a eso descentralizado depende de lo que creas que significa la palabra.
¿Fueron 250.000 dólares suficientes para un error de 94.000 millones?
Veria Labs recibió el pago máximo del nivel crítico del programa XRPL de 250.000 dólares el 8 de octubre. Veria lo calificó como probablemente la mayor recompensa jamás pagada por un error encontrado enteramente por un agente de IA. Cuatro días después, el investigador de blockchain ZachXBT lo calificó de mal chiste. Su argumento: un ecosistema cuyo tesoro tiene miles de millones pagó un cuarto de millón por un hallazgo que podría haber acabado con el activo. Y esa brecha es exactamente el incentivo que empuja al siguiente investigador a vender a un atacante en su lugar. Sugirió siete cifras como mínimo y señaló una recompensa de siete cifras supuestamente pagada en el ecosistema Zcash por un reciente error de falsificación. Ni Ripple ni la Fundación habían respondido públicamente en el momento de escribir esto.
Ambas partes tienen razón en cosas diferentes. El programa pagó su máximo anunciado, el investigador divulgó de forma responsable y la solución llegó antes de que nadie fuera del círculo lo supiera. Eso es el sistema funcionando. También es cierto que 250.000 dólares son el 0,27 por ciento de los 94.000 millones en riesgo, y que cualquier atacante con 256 cuentas y unos cientos de XRP podría haberse llevado el otro 99,73 por ciento. Los techos de recompensas escritos cuando XRP valía una fracción de su valor de mercado actual no escalan con lo que protegen.
Qué deberían sacar de esto los tenedores de XRP y los jugadores de cripto
La solución es del lado del servidor. Tu monedero, tus claves y tu saldo nunca estuvieron involucrados y no hay nada que actualizar por tu parte. El límite de suministro se mantuvo porque el error fue detectado, no porque el invariante funcionara. La segunda mitad de esa frase es la que vale la pena recordar.
Hay tres lecciones prácticas aquí. Primera, que el código haya estado activo durante diez años ha dejado de ser un argumento de seguridad. La auditoría asistida por IA está haciendo que los desbordamientos antiguos sean baratos de encontrar, y los atacantes alquilan los mismos modelos que los investigadores. Segunda, los procesos de gobernanza diseñados para despliegues de funciones no están diseñados para parches críticos. Y cada cadena debería decidir de antemano cómo manejará el siguiente en lugar de improvisar bajo presión. Tercera, los techos de recompensas por errores deberían seguir el valor asegurado. Un límite fijo que parecía generoso en 2022 es una invitación en 2026. Además, para el público de juego la relevancia es simple. XRP se ha convertido en un riel de depósito estándar en los casinos cripto porque se liquida en cuatro segundos por una fracción de céntimo. Y esa velocidad depende de que las reglas del ledger sean correctas. Las plataformas que automatizan los pagos, incluida CryptoCasino.Vegas, confían en los invariantes de la cadena cada vez que un retiro de XRP se completa sin que un humano lo revise. Esos invariantes se mantuvieron esta vez gracias a un investigador y un agente de IA trabajando toda la noche, y ese es un margen más fino de lo que el límite de 100 mil millones dejaba entrever.
El desglose técnico completo, incluyendo ambas ubicaciones de desbordamiento y la aritmética reforzada que las reemplazó, está en el informe de divulgación de vulnerabilidades de la Fundación XRPL para xrpld 3.4.1.
