Ripple ha anunciado una doble estrategia para reforzar la seguridad del XRP Ledger (XRPL): por un lado, propone eliminar más de 10.000 líneas de código sin uso procedentes del XChainBridge; por otro, ha sometido la versión 1.1 de su protocolo de préstamos nativos a una auditoría de seguridad realizada íntegramente por inteligencia artificial a través del Audit Engine de Sherlock.
El movimiento llega en un contexto en el que las plataformas cripto se enfrentan a una presión creciente por endurecer sus defensas. Durante la primera mitad de 2026 se perdieron más de 1.310 millones de dólares en 344 incidentes de seguridad, y las vulnerabilidades de código siguen siendo la categoría de ataque más común en la industria, según CertiK.
XChainBridge: código sin demanda real
El código original de XChainBridge (XLS-38) fue diseñado para permitir que activos se movieran entre XRPL y las sidechains conectadas mediante servidores testigo que observan transacciones y certifican la actividad entre redes. La arquitectura tenía como objetivo servir de puente entre la mainnet de XRPL y el EVM Sidechain, además de soportar sidechains privadas, permisionadas y experimentales.
Sin embargo, Ripple finalmente optó por Axelar para el EVM Sidechain tras evaluar seguridad, experiencia de usuario, descentralización y las cargas operativas de mantener un puente. La compañía concluyó que el modelo de testigos de XLS-38 implicaba compromisos difíciles de gestionar a medida que aumentaba el valor protegido por el puente. Ampliar el conjunto de testigos mejoraba la descentralización, pero añadía complejidad de coordinación y gobernanza; un grupo más pequeño, por su parte, concentraba más confianza entre los operadores.
Aunque Ripple anunció su decisión de utilizar Axelar en junio de 2024, mantuvo XLS-38 disponible para un voto de validadores y dio a los desarrolladores entre 12 y 15 meses para demostrar demanda por sidechains privadas que realmente necesitaran la enmienda. Esa demanda nunca alcanzó el nivel esperado, dejando un bloque considerable de código inactivo que los desarrolladores deben seguir manteniendo y revisando pese a que su caso de uso principal se cubre ahora por otra vía.
Ripple estima que retirar XChainBridge y la enmienda relacionada fixXChainRewardRounding terminaría eliminando más de 10.000 líneas del código xrpld. La empresa identifica el coste de mantenimiento, la complejidad para los colaboradores y la superficie de ataque como razones para no conservar funcionalidades inactivas, argumentando que XRPL debe permanecer ágil mientras evoluciona.
La recomendación no retira XLS-38 de inmediato. Ripple controla un voto de validador, y la propuesta queda sujeta al proceso de enmiendas del XRPL. Si la comunidad apoya el cambio, Ripple planea primero marcar XChainBridge como obsoleto. Los validadores que adopten una versión del software que incluya esa designación dejarían de votar por la enmienda, permitiendo eliminar el código en una versión posterior una vez que la red converja.
Protocolo de préstamos: inteligencia artificial en primera línea
Reducir código heredado coincide con la preparación de XRPL para introducir infraestructura de préstamos, que implicará muchas más interacciones financieras que asegurar. El protocolo de préstamos V1.1 se apoya en la apuesta de Ripple por llevar capacidades nativas de préstamo al XRPL, junto con Single Asset Vaults. La arquitectura subyacente combina gestión del ciclo de vida de créditos, cálculos de tipos de interés, enrutamiento de comisiones entre múltiples partes, permisos basados en credenciales e interacciones con pools de activos.
Ripple ha descrito el sistema de préstamos como una de las adiciones financieras más complejas desarrolladas para XRPL desde el lanzamiento de la red. El 27 de agosto, Sherlock anunció que V1.1 había entrado en una revisión de seguridad intensiva realizada exclusivamente por inteligencia artificial mediante su Audit Engine. El sistema combina múltiples auditores de IA y modelos frontera con capacidades especializadas en seguridad, ajustando cobertura y profundidad según el protocolo examinado.
Sherlock no ha publicado resultados ni fecha de conclusión. Anunció que ofrecería un informe más completo una vez finalizara el proceso. La revisión sigue a un proceso de seguridad inusualmente exhaustivo para la base de código anterior de préstamos y Single Asset Vault, donde pruebas repetidas hallaron vulnerabilidades incluso después de rondas previas de escrutinio.
Ripple e Immunefi organizaron un atacatón de 200.000 dólares a finales de 2025 que cubrió 35.498 líneas de código. Atrajo 455 envíos de 131 investigadores y produjo 94 hallazgos válidos únicos, incluidos 15 clasificados como críticos y 19 como de gravedad alta. Ripple confirmó que corrigió todos los problemas identificados.
Posteriormente, la compañía sometió el sistema de préstamos a auditorías adicionales, pruebas comunitarias, fuzzing y un programa de red-team asistido por IA. Entre marzo y mayo, el equipo de red-team de IA de Ripple abrió 20 tickets específicos de préstamos e identificó siete errores confirmados que fueron corregidos. Entre ellos figuraban un invariante invertido que podría haber permitido que colateral fantasma pasara desapercibido, un vector de spam sin comisiones relacionado con pagos de préstamos y un problema de desbordamiento de enteros que podría haber causado un bloqueo del nodo.
Contexto del sector: vulnerabilidades al alza
La ampliación del programa de seguridad de XRPL coincide con un entorno de ataque en toda la industria que sigue siendo costoso pese a años de auditorías y programas de recompensas por errores. En julio, CertiK registró 1.315 millones de dólares en pérdidas a través de 344 incidentes de seguridad durante los primeros seis meses de 2026. Aunque esa cifra fue inferior a la del año anterior, el primer semestre de 2025 incluyó el excepcional hackeo de Bybit por 1.450 millones de dólares. Excluyendo ese evento, CertiK calculó que las pérdidas comparables aumentaron aproximadamente un 28% este año.
Las vulnerabilidades de código fueron el tipo de ataque más frecuente, apareciendo en 204 incidentes. CertiK también constató que los atacantes estaban volviendo cada vez más a contratos de más de un año de antigüedad, lo que muestra cómo las vulnerabilidades pueden seguir siendo explotables mucho después de que el software haya sido desplegado.
Algunas de las mayores pérdidas provinieron de otras debilidades. Los compromisos de carteras generaron más de 444 millones de dólares en pérdidas, mientras que el compromiso RPC de Kelp DAO y la brecha de Drift Protocol sumaron conjuntamente 576 millones de dólares. Esa distinción es significativa porque ninguna auditoría de código, impulsada por IA o no, aborda todas las amenazas de seguridad que enfrenta un protocolo o sus usuarios.
Ripple ha estado, en consecuencia, empleando varias capas de pruebas en lugar de confiar exclusivamente en la inteligencia artificial. Su proceso de desarrollo de préstamos ha incluido auditorías independientes, competiciones públicas de seguridad, fuzzing, métodos formales, pruebas comunitarias y descubrimiento de vulnerabilidades asistido por IA. Los propios investigadores de seguridad de Ripple han advertido contra tratar la IA como un sustituto de la revisión experta, señalando que sus pipelines de IA producen falsos positivos y que la validación humana sigue siendo especialmente importante para errores sutiles donde un modelo puede malinterpretar cómo se supone que debe comportarse un invariante.
Por ahora, Sherlock no ha publicado resultados de su revisión por IA. Ripple está, por tanto, intentando reducir fuentes conocidas de complejidad innecesaria en una parte de XRPL mientras somete la próxima generación de funcionalidad financiera a un escrutinio cada vez más agresivo antes de que más valor dependa de ella.
Fuente: CryptoSlate · Esta información ha sido elaborada por la redacción de Criptonews con apoyo de herramientas editoriales automatizadas.