Por Canuto  

XRP Ledger prevé activar el 4 de noviembre fixCleanup3_4_0, una actualización destinada a cerrar una brecha por la que el permiso delegado PaymentBurn podía permitir la creación de tokens. La enmienda reúne el respaldo de 33 de los 35 validadores de confianza, aunque su activación se retrasó después de que una caída temporal del apoyo reiniciara la cuenta regresiva.

***

  • La actualización está prevista para alrededor de las 14:46 UTC del 4 de noviembre de 2026.
  • La corrección obtuvo 33 votos de 35 validadores; se requieren al menos 29 para superar el umbral de más del 80%.
  • La documentación de XRPL recomienda no delegar PaymentBurn hasta que fixCleanup3_4_0 entre en vigor.

 

 

XRP Ledger tiene previsto activar fixCleanup3_4_0 alrededor de las 14:46 UTC del 4 de noviembre de 2026, una actualización que busca cerrar una brecha en los permisos delegados de la red. El problema podía permitir que una cuenta autorizada para quemar tokens también creara algunos nuevos, por lo que la advertencia concierne especialmente a emisores, plataformas de intercambio y empresas que administran permisos de cuenta.

La enmienda cuenta con el respaldo de 33 de los 35 validadores de confianza, según el rastreador de actualizaciones de Xrpscan citado por Bitcoin.com News. Para activar una enmienda se requiere el apoyo de más del 80% de los validadores de confianza: en este caso, al menos 29 de 35. Aunque la corrección supera ese umbral, su calendario se retrasó después de que el apoyo de los validadores cayera brevemente y la cuenta regresiva se reiniciara.

Qué problema corrige fixCleanup3_4_0

La brecha se relaciona con PermissionDelegationV1_1, una enmienda que entró en funcionamiento el 8 de octubre y permite que una cuenta conceda facultades específicas a otra sin compartir sus claves. Entre esos permisos figura PaymentBurn, diseñado para que una cuenta delegada pueda destruir tokens bajo las condiciones establecidas. El fallo estaba en que esa facultad podía abrir una posibilidad adicional: crear tokens fungibles en determinadas circunstancias.

La documentación de XRPL advierte que, antes de la corrección, un delegado con PaymentBurn también podía acuñar nuevos tokens fungibles. El escenario podía involucrar tokens de línea de confianza o tokens multipropósito, conocidos como MPT, aunque la advertencia no indica que cualquier uso del permiso produjera automáticamente ese resultado. Por esa razón, la recomendación vigente antes del parche es no delegar esa facultad granular.

El alcance reportado se limita a PaymentBurn y no implica que todos los permisos delegados presenten el mismo problema. Esa distinción importa para empresas y emisores que separan las tareas de administración de una cuenta sin entregar sus claves principales. La falla no supone, según la información publicada, que los titulares habituales de XRP deban cambiar su comportamiento o tomar medidas sobre sus saldos.

La corrección forma parte de xrpld 3.4.0, el paquete de software que incluye los cambios asociados a la versión 3.4.0. Entre ellos figura el rechazo de pagos PaymentBurn que superen un saldo de cero. Las notas de la versión también incorporan ajustes para recuperaciones de creadores de mercado automatizados, contabilidad de cajas fuertes, reservas de depósito en garantía y gestión de firmas; a los operadores de nodos se les recomendó actualizar cuanto antes.

Un plazo sujeto al respaldo de los validadores

Las enmiendas de XRPL no se activan únicamente porque se publique una actualización de software: deben conservar más del 80% de apoyo de los validadores de confianza durante dos semanas consecutivas. Si el respaldo cae al 80% o menos en cualquier momento de ese período, el contador se reinicia. Ese mecanismo explica por qué una fecha estimada puede cambiar incluso cuando una enmienda había alcanzado previamente el nivel requerido.

A mediados de octubre, fixCleanup3_4_0 apuntaba a activarse alrededor de las 09:34 UTC del 23 de octubre. Sin embargo, esa fecha pasó y el conteo de dos semanas tuvo que recomenzar el 21 de ese mes, de acuerdo con el reporte. Al momento de la información, la actualización había recuperado apoyo suficiente y sumaba 33 votos, frente a los 29 que necesita para superar el mínimo de aprobación entre 35 validadores.

La activación prevista para el 4 de noviembre depende, por tanto, de que la enmienda complete el período requerido sin perder el respaldo necesario. Los 33 votos representan una mayoría superior al umbral, pero no eliminan la condición de mantenerla durante dos semanas consecutivas. Hasta que el cambio entre en vigor, la recomendación de la documentación sigue siendo evitar la delegación de PaymentBurn.

Una vez activa fixCleanup3_4_0, el objetivo es que la facultad de quemar tokens ya no permita el comportamiento de emisión descrito en la advertencia. El cambio tendría consecuencias prácticas para quienes conceden permisos a terceros, no para todos los usuarios de la red por igual. La diferencia entre publicar el parche y completar su activación mediante consenso también muestra que los operadores deben seguir tanto la versión del software como el estado de la enmienda.

Otras propuestas y el contexto de seguridad de XRPL

Otras enmiendas pendientes están más lejos de alcanzar el umbral de 29 votos. LendingProtocolV1_1 y la propuesta original LendingProtocol reunían 19 votos cada una, mientras SingleAssetVault contaba con 21. Ninguna tenía una cuenta regresiva activa en el rastreador mencionado en el reporte, por lo que sus respectivos cambios todavía no estaban encaminados a una activación inmediata.

En conjunto, esas propuestas buscan introducir préstamos nativos en XRP Ledger, pero su falta de apoyo suficiente mantiene esos planes en suspenso. La situación contrasta con el impulso de otras actividades en la red, aunque no significa que las propuestas de préstamos hayan sido aprobadas o que exista una fecha para su entrada en vigor. El reporte también señaló que la stablecoin RLUSD de Ripple había recibido recientemente apoyo de Coinbase en XRP Ledger y otras cadenas.

La corrección se conoce después de que desarrolladores revelaran el mes anterior un error de una década en el libro mayor que, de acuerdo con el reporte, podría haber permitido acuñar XRP por encima de su suministro fijo. Ese problema se corrigió discretamente en septiembre y no había pruebas de que alguien lo hubiera aprovechado. Se trata de un antecedente distinto de la falla de PaymentBurn, aunque ambos casos colocan la seguridad del protocolo en el centro de la atención.

El artículo también recordó que XRP fue el primer activo afectado por el ataque reciente a Binance, pero aclaró que el incidente apuntó a carteras de Binance y no a XRP Ledger. Esa precisión evita confundir un problema en una plataforma con una vulnerabilidad de la propia red. Antes de la actualización, el precio de XRP se encontraba cerca de USD $1,25 el 3 de noviembre, sin que el reporte atribuyera ese nivel a la falla o al parche.

En términos prácticos, el próximo paso para emisores, plataformas y operadores consiste en comprobar que la actualización se active y seguir la recomendación sobre PaymentBurn hasta entonces. El calendario depende del procedimiento de consenso, mientras que la corrección está incorporada en xrpld 3.4.0 y no cambia las instrucciones para los titulares comunes de XRP. La noticia, por tanto, combina una solución técnica concreta con una advertencia temporal para quienes delegan permisos de emisión y destrucción de tokens.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público

Este artículo fue escrito por un redactor de contenido de IA




ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados