Los desarrolladores del XRP Ledger han lanzado un parche de seguridad de emergencia en respuesta a un error crítico que habría permitido a actores maliciosos generar XRP adicional gastable, a pesar del suministro fijo de 100 mil millones de tokens de la red.

La corrección omitió el proceso estándar de votación de validadores de dos semanas del ledger —una decisión que los desarrolladores justificaron argumentando que esperar habría dado a los posibles atacantes tiempo para explotar la debilidad. El parche se implementó con efecto inmediato tres días después de que el error fuera reportado a través del programa de bug bounty de la red, que recompensa a los investigadores por divulgar de manera responsable fallas de seguridad, y los desarrolladores señalaron que marcó la primera omisión intencional del proceso de enmiendas en más de diez años.

Desde entonces, la respuesta ha generado un amplio debate sobre cómo el XRP Ledger gestiona situaciones críticas, así como sobre su compromiso con la descentralización.

El parche de emergencia omitió la aprobación de los validadores

Las enmiendas al protocolo del XRP Ledger normalmente requieren más del 80% de consenso entre los validadores durante un período de dos semanas antes de que un cambio entre en vigencia —un umbral diseñado para garantizar que los cambios en las reglas de la red cuenten con un amplio acuerdo antes de activarse. Los desarrolladores señalaron que esperar el resultado de una votación sobre el parche de seguridad podría haber dejado la vulnerabilidad abierta a explotación.

Según una publicación en el blog difundida el domingo por los desarrolladores del XRP Ledger, el proceso normal de enmiendas podría haber dejado la corrección expuesta durante varias semanas antes de que la enmienda se activara, poniendo así en peligro la red.

Si bien el parche de emergencia entregó una resolución rápida, la decisión de eludir el proceso habitual ha generado preguntas sobre el papel que desempeñan los equipos de desarrollo al responder a brechas de seguridad.

La Foundation aclara que no se creó XRP

La XRP Ledger Foundation se apresuró a disipar la confusión tras la corrección:

The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let's clear them up. 1. Was any XRP created? No. XRP's supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around… — XRP Ledger Foundation (@XRPLF) October 11, 2026

El parche desata un debate sobre la descentralización

La respuesta de emergencia ha reavivado la controversia sobre si el XRP Ledger es descentralizado —una cuestión que ha sido uno de los temas principales para determinar la situación legal de XRP. El grado de control que un equipo central conserva sobre una red ha sido una consideración recurrente cuando los reguladores evalúan cómo debe clasificarse un activo digital.

Justin Bons, cofundador de Cyber Capital, fue muy crítico con la actualización de emergencia, argumentando que hablar de la descentralización de XRP es engañoso:

Selling XRP to retail as "decentralized" is straight-up fraud! 🚩 XRP has been running closed-source code for the last two weeks Tomorrow, this code mandatory & anyone who disagrees will get kicked off the chain! A permissioned node list means validators must obey: 🧵… pic.twitter.com/3nIcRiid8S — Justin Bons (@Justin_Bons) October 8, 2026

En su publicación, Bons afirmó que la red había estado ejecutando código cerrado durante dos semanas antes de una actualización obligatoria, y que una lista de nodos con permisos efectivamente exigía a los validadores cumplir.

Otra preocupación adicional es que las distribuciones binarias son archivos ejecutables: ante la falta de una distribución oportuna del código fuente subyacente, los desarrolladores independientes tienen tiempo limitado para analizar los cambios realizados.

La XRP Ledger Foundation explicó que el parche de emergencia fue "acordado conjuntamente" por la Foundation, RippleX, los desarrolladores y los validadores debido a la gravedad del error encontrado en el código. La organización enfatizó que nadie dictó el proceso de toma de decisiones y que los operadores siguen siendo libres de usar el software que prefieran.

El operador de validadores XRP Kuwait también respaldó el proceso de parcheo de emergencia, afirmando que la colaboración no significa centralización:

Our Statement on xrpld 3.4.1 At XRP Kuwait, our journey has always been about infrastructure and purpose. Our purpose is decentralization. We pursue that purpose through independently operated infrastructure and responsible participation in the XRP Ledger. Following the… pic.twitter.com/Oo7qClwpgi — XRPKuwait (@XRPKuwait) October 11, 2026

La controversia ha vuelto a poner en duda la transparencia y la rendición de cuentas durante los parches de emergencia.

Desbordamiento de enteros en el motor de pagos

La falla detrás del parche de emergencia fue detallada en una divulgación del equipo del XRP Ledger. Según el informe de vulnerabilidad, el problema era un desbordamiento de enteros en el motor de pagos que persistía desde 2015. Los desbordamientos de enteros son una clase de error de software conocida desde hace mucho tiempo, en la que un cálculo excede el valor máximo que un sistema puede almacenar y se reinicia a un número mucho menor; en este caso, los cálculos por encima del límite máximo fijo producían resultados más pequeños.

Un atacante podría haber explotado el error enviando cientos de ofertas solicitando enormes cantidades de XRP a cambio. Tras el cálculo defectuoso, el atacante habría recibido esas cantidades mientras el comprador pagaba menos del monto requerido —lo que potencialmente habría resultado en XRP adicional gastable.

Dado que las reglas de la red fijaron el suministro total de XRP en 100 mil millones de tokens desde el lanzamiento, cualquier vía para producir XRP adicional gastable habría socavado una garantía central del ledger —la regla de suministro fijo que sustenta la escasez del activo.

El ataque requería ofertas especialmente diseñadas y no podía ocurrir durante el curso normal del comercio. El parche fue diseñado para impedir que el error de cálculo se usara para eludir las reglas de suministro de la red.

RippleX amplía sus esfuerzos de seguridad

RippleX tiene la intención de fortalecer la seguridad del XRP Ledger mediante la detección de vulnerabilidades impulsada por IA, pruebas adversariales, verificación formal y colaboración con expertos externos en seguridad.

Los objetivos de estos esfuerzos incluyen encontrar errores en el código, probar posibles ataques e identificar vulnerabilidades antes de que puedan ser explotadas. RippleX ha presentado el trabajo como un esfuerzo por mejorar la seguridad de todo el sistema de código, en lugar de simplemente corregir vulnerabilidades detectadas.

Equilibrar seguridad y transparencia

La corrección de emergencia destaca el desafío de mantener la seguridad de la blockchain preservando la transparencia en la toma de decisiones. Aunque la implementación rápida es esencial para protegerse contra posibles ataques, plantea cuestiones sobre los procesos de gobernanza y el acceso al código fuente.

Los desarrolladores sostuvieron que la vulnerabilidad hacía necesario omitir el procedimiento estándar, mientras que la Foundation afirmó que la coordinación entre las partes involucadas no afectó la independencia de los validadores.

El incidente subraya la necesidad de desarrollar protocolos de emergencia que concilien la respuesta rápida con la apertura de la red.

Fuente: Tron Weekly