El parche de XRP Ledger (XRPL) conservaba el 19 de octubre de 2026 la mayoría necesaria para activarse a partir del 23 de octubre, si mantiene el apoyo. Los préstamos nativos seguían sin aprobación, según XRPL Dashboard.
El panel registró, a las 22:22 UTC, 29 votos para fixCleanup3_4_0 entre 35 validadores de confianza observados. Con ese conjunto, perder un apoyo dejaría el respaldo en el 80 % y reiniciaría la espera.
LendingProtocol y LendingProtocolV1_1 tenían 19 votos cada uno; SingleAssetVault, que reuniría los fondos de los depositantes, contaba con 21. Sus plazos de activación seguían pendientes.
El corte compara los apoyos con el mínimo de 29:
| Enmienda | Apoyos de 35 | Faltan para 29 | Estado |
|---|---|---|---|
| fixCleanup3_4_0 | 29 | 0 | Plazo en curso |
| LendingProtocol | 19 | 10 | Sin mayoría |
| LendingProtocolV1_1 | 19 | 10 | Sin mayoría |
| SingleAssetVault | 21 | 8 | Sin mayoría |
El plazo termina antes de la activación efectiva
Las reglas oficiales de XRPL exigen más del 80 % de apoyo durante dos semanas continuas. El panel sitúa el inicio de la mayoría del parche el 9 de octubre y el fin de ese plazo a las 09:34 UTC del 23 de octubre: 03:34 del centro de México, 05:34 del Este de Estados Unidos y 11:34 de España peninsular.
La aplicación efectiva llega después. El protocolo evalúa las enmiendas cada 256 registros del libro contable, en un ciclo llamado flag ledger; incorpora el cambio en el registro siguiente y aplica sus reglas desde el posterior. Por eso, las 09:34 UTC son una referencia condicionada, no una hora garantizada de entrada en funcionamiento.
Para los préstamos, sumar las dos semanas obligatorias a una hipotética mayoría alcanzada el 19 de octubre llevaría el primer vencimiento posible al 2 de noviembre. Es un cálculo del plazo mínimo: cada propuesta necesita obtener y sostener sus propios votos.
Qué corrige el parche
La documentación de XRPL describe un fallo de permisos por el que una cuenta autorizada a destruir tokens podía, en determinadas circunstancias, emitirlos. La corrección limita ese comportamiento al permiso concedido. El problema afecta a tokens emitidos sobre la red; no supone crear nuevos XRP.
El paquete también ajusta los redondeos al depositar y retirar activos de los fondos compartidos, y exige que la fecha de pago haya pasado para determinadas comprobaciones de mora e impago. Incluye correcciones en los mecanismos automatizados de intercambio y en la validación de operaciones.
La propuesta separada LendingProtocolV1_1 añade fondos cerrados con fases de suscripción, inversión y reembolso. También reconoce los intereses como ingreso cuando se cobran, en lugar de registrar de entrada todos los intereses previstos. Esas fases determinan cuándo se admite dinero, cuándo se presta y cuándo puede retirarse.
El riesgo del préstamo sigue en el prestatario y el intermediario
Según la documentación del Lending Protocol, el diseño permite préstamos a plazo fijo y sin garantía, financiados con aportaciones agrupadas. La evaluación de solvencia ocurre fuera de la cadena y depende del intermediario que organiza los créditos.
Ese intermediario puede aportar capital propio para absorber primeras pérdidas. La protección es opcional y la documentación advierte que no elimina el riesgo crediticio. Corregir un redondeo o el reconocimiento de intereses mejora la ejecución y la contabilidad; el cobro sigue dependiendo de que el prestatario pague.
Para un futuro depositante, las condiciones materiales seguirían siendo quién evalúa al prestatario, cuánta pérdida cubre el intermediario y en qué fase puede recuperar sus fondos. La activación del parche corregiría parte del funcionamiento técnico; la disponibilidad del crédito depende de las votaciones que siguen abiertas.
