La documentación oficial de XRP Ledger (XRPL) aconseja a los titulares de cuentas no delegar el permiso PaymentBurn hasta que una enmienda llamada fixCleanup3_4_0 se active en la red. La advertencia se centra en una falla en el límite entre quemar y emitir tokens, que en ciertas circunstancias permitía que un delegado solo de quema emitiera nuevos tokens en lugar de destruirlos. La falla no puede crear nuevo XRP en sí, pero toca precisamente la tarea que la delegación de permisos estaba diseñada para mantener bajo llaves fuera de línea.

Para qué servía un delegado solo de quema

La delegación de permisos permite que una cuenta encomiende tareas específicas a una segunda cuenta, la cual firma con sus propias claves. La documentación de XRPL es explícita sobre el propósito: el trabajo rutinario se ejecuta con claves mantenidas en línea, mientras que las claves con control total permanecen fuera de línea para tareas especiales como la emisión de tokens. La guía de Coindoo sobre los controles de cuentas delegadas de XRPL explica cómo las instituciones podrían dividir esos roles.

Dos de los doce permisos granulares del ledger se relacionan con la oferta de tokens. PaymentMint cubre los pagos que crean tokens fungibles o Multi-Purpose Tokens (MPT). PaymentBurn cubre los pagos que los destruyen, y la documentación establece su límite con precisión: la quema se detiene en un saldo cero.

La falla se encuentra justo en ese límite. Antes de la corrección, un pago enviado bajo PaymentBurn podía, en ciertas circunstancias, rebasar el cero y emitir nuevos tokens de trust-line o MPT. fixCleanup3_4_0 rechaza cualquier pago delegado solo de quema cuyo monto cruce hacia la emisión, a menos que el mismo delegado también tenga PaymentMint. Los otros once permisos granulares no se ven afectados.

Esto hace que el error sea de alcance reducido, pero incómodo en lo que toca. Solo puede utilizarlo una cuenta que un emisor ya haya elegido como delegado, pero lo que desbloquea es la emisión: justamente la tarea que la delegación debía mantener bajo llaves fuera de línea.

El almacenamiento en frío no cubre las claves de un delegado

Las transacciones delegadas se firman con la clave maestra del delegado, su clave regular o su lista de multifirma. Un emisor puede mantener sus credenciales principales completamente fuera de línea y aun así quedar expuesto si un delegado con PaymentBurn es comprometido, está mal configurado o actúa fuera de su mandato.

Para un token respaldado por fiat, el riesgo económico son unidades en circulación sin reservas que las respalden. Una certificación de reservas muestra los activos mantenidos contra los tokens en circulación en una fecha de reporte. No dice nada sobre qué cuentas podrían cambiar esa cifra entre reportes, y ese es el control que esta falla debilita.

La delegación se lanzó antes de que su corrección tuviera los votos

Esta es la segunda falla encontrada en la función de delegación de XRPL. La versión original fue retirada en 2025 después de que un probador de la comunidad descubriera en devnet que podía cobrar tarifas de transacción a cuentas que no habían firmado, y la divulgación oficial confirma que nunca llegó a la Mainnet. Su reemplazo, PermissionDelegationV1_1, se activó el 8 de octubre, según el panel de enmiendas de XRPL, mientras la corrección de PaymentBurn aún reunía el respaldo de los validadores.

Por lo tanto, la exposición es cuenta por cuenta: solo se ven afectados los emisores que otorgaron PaymentBurn desde el lanzamiento. Cada concesión es pública, porque las entradas Delegate del ledger registran la cuenta otorgante, el delegado y su lista de permisos. Al momento de escribir esto, ni la documentación de XRPL ni los reportes publicados identifican un emisor afectado o algún uso indebido.

Un aumento de oferta por sí solo no probaría nada, ya que un emisor puede haber otorgado PaymentMint deliberadamente. Lo que necesitaría explicación es un delegado que tuviera solo PaymentBurn y cuyos pagos agregaran tokens.

Qué pueden revisar los emisores antes del miércoles

El consejo publicado de XRPL es dejar de delegar PaymentBurn hasta que la corrección se active. Para los emisores que ya la han otorgado, el trabajo sigue este orden:

1. Extraer cada entrada Delegate de la cuenta emisora y marcar cualquier lista de permisos que contenga PaymentBurn.
2. Reenviar DelegateSet con la lista completa de permisos que se desean conservar. Una nueva lista reemplaza a la anterior, por lo que todo lo que se omita queda eliminado.
3. Considerar revocada una concesión solo cuando el cambio aparezca en un ledger validado.
4. Auditar por separado los pagos anteriores del delegado, porque revocar la autoridad detiene el uso futuro sin revertir las transacciones anteriores.
5. Volver a delegar PaymentBurn solo después de que fixCleanup3_4_0 aparezca como activada en la Mainnet.

Por qué la votación aún puede demorarse

Bajo las reglas oficiales de enmiendas, un cambio necesita una supermayoría de validadores de confianza mantenida durante dos semanas ininterrumpidas. Con 35 validadores en el conjunto monitoreado, ese umbral es 29, y caer por debajo lo reinicia. Ese reinicio ya ocurrió una vez; el respaldo actualmente se sitúa en 33 de los 35 validadores de confianza que apoyan la corrección.

Incluso con el respaldo intacto, las 14:46 UTC marcan la apertura de la ventana de dos semanas. La activación ocurre en un punto de control de votación del ledger, por lo que el cambio puede entrar en vigor algún tiempo después.

Los validadores también están votando sobre mucho más que esta sola corrección. fixCleanup3_4_0 agrupa 25 cambios en bóvedas, préstamos, creadores de mercado automatizados, NFT, escrow y patrocinio, y la corrección de PaymentBurn es el último elemento de su lista. Corrige el código de préstamos sin activar el Lending Protocol en sí, que tiene su propia enmienda aún abierta a votación.

Para los emisores, la confirmación que cuenta es que fixCleanup3_4_0 figure como activada en la Mainnet. Hasta entonces, una concesión de PaymentBurn otorga más autoridad de la que su nombre sugiere.

Este artículo apareció originalmente en Coindoo.