XRP Ledger: dos correcciones propuestas refuerzan las autorizaciones de tokens restringidos

La autorización debe acompañar a los activos del pool

Los desarrolladores de XRP Ledger examinan cambios para aplicar con mayor coherencia las autorizaciones exigidas por los emisores de determinados tokens. Dos solicitudes de modificación abiertas en el repositorio rippled, numeradas 8648 y 8650, abordan vías por las que una cuenta podría recibir exposición sin el permiso esperado. El asunto reapareció en la actualidad del 30 de octubre de 2026, pero sus textos técnicos son anteriores. Se trata de código propuesto y debatido, no de un anuncio que demuestre que una nueva regla ya está activa en la red principal.

El primer cambio afecta a los tokens que representan una participación en un pool automatizado. Esa participación da exposición a ambos activos del pool. El control durante un depósito inicial no basta si el token puede cambiar posteriormente de titular por otras vías. El texto describe pagos, ofertas y ciertos reembolsos, entre otros casos. La corrección busca exigir las autorizaciones de ambos activos cuando una cuenta adquiere la participación, no solo cuando aporta directamente liquidez.

Una posición existente no debe eludir el control

El segundo cambio aborda otro caso: en la vía descrita, el control de autorización de un pago solo se activaba cuando el saldo de la línea de confianza era exactamente cero. Una cuenta que ya tuviera saldo podía recibir más sin cumplir la regla esperada. La corrección propuesta busca cerrar esta excepción. La descripción se refiere a activos emitidos con restricciones; no significa que todo pago en XRP nativo deba ser aprobado ahora por un emisor de tokens.

Ambos cambios se presentan bajo el nombre de enmienda técnica fixCleanup3_5_0. El repositorio explica que la propuesta inicial se dividió para facilitar su revisión. Dos capas adicionales, relativas a la gestión de saldos y a una regla de coherencia, se cerraron tras el examen. Describir todavía el asunto como cuatro solicitudes abiertas no correspondería al estado de los documentos primarios consultados. El cierre también debe interpretarse en el contexto de revisión, sin equipararlo automáticamente a una puesta en producción.

Proponer, integrar y activar son etapas distintas

El estado de una solicitud indica el avance de su integración en el software. No basta, por sí solo, para establecer el comportamiento de la red que utilizan los titulares. Un cambio aceptado debe seguir todavía el proceso aplicable de despliegue y activación. Los textos examinados no permiten pedir a los lectores que consideren estos controles ya generalizados. Documentar un cambio efectivo exigirá relacionar el código aceptado, la versión distribuida y el estado real de la enmienda.

Para las aplicaciones que utilizan activos restringidos, lo importante es la coherencia de las autorizaciones entre distintos tipos de operaciones. Los efectos buscados conciernen a la adquisición de exposición y a la recepción de nuevos saldos, con las salidas tratadas por separado en las propuestas. La mera existencia de este trabajo no prueba un robo ni perjuicios a usuarios. La lectura útil se centra en las vías técnicas corregidas y en su estado verificado, sin convertir un refuerzo propuesto en un incidente confirmado o una regla ya vigente.