Los validadores de XRP Ledger activaron la enmienda fixCleanup3_4_0 el 4 de noviembre a las 14:52 UTC, cerrando una brecha de casi cuatro semanas durante la cual una quema delegada de tokens podía empujar el saldo de una cuenta por debajo de cero. Coindoo confirmó la transacción de activación en el ledger validado 108,112,129, y el servidor público de Mainnet de Ripple muestra la enmienda como habilitada.

La activación llegó tras una votación que perdió brevemente su supermayoría a finales de octubre, un contratiempo que se siguió en el informe previo a la activación de Coindoo. Ese informe establecía la lista de verificación que se recomendaba ejecutar a los emisores. El código y la prueba enviados con la corrección responden a una pregunta más acotada: los tokens de quién creó realmente el exceso.

Casi Cuatro Semanas Sin una Verificación de Saldo Cero

La delegación se activó el 8 de octubre bajo la enmienda PermissionDelegationV1_1, según el panel de enmiendas de XRPL. Desde entonces hasta el 4 de noviembre, un delegado con PaymentBurn podía, en algunas configuraciones, llevar un rescate más allá de cero. Por ello, la referencia de permisos de XRPL recomendaba no delegar ese permiso hasta que esta enmienda estuviera habilitada. Esa condición se cumplió el 4 de noviembre.

El commit de rippled detrás de la corrección, escrito bajo el handle de GitHub yinyiqian1, añade la verificación faltante. Cuando un delegado solo tiene PaymentBurn, el ledger compara el monto del pago con el saldo que la cuenta realmente posee y rechaza cualquier monto mayor. La documentación de XRPL ya describía la quema como algo que se detenía en cero; para pagos delegados, el código no aplicaba ese límite hasta esta enmienda.

Dentro de la Prueba: Alice, un Gateway y un Pago Excesivo

La prueba del commit usa tres cuentas. Alice posee 50 USD emitidos por una cuenta llamada gateway. Gateway, a su vez, ha abierto una línea de confianza que acepta hasta 200 USD emitidos por alice, lo que los comentarios del código describen como dar al motor de pagos "liquidez de emisión disponible una vez que la trustline llega a cero".

Luego, Alice otorga a una tercera cuenta, bob, el permiso PaymentBurn, y bob envía un pago de alice a gateway por el doble de lo que ella posee. El rastro muestra cómo el ledger manejó ese pago, y los pagos siguientes, bajo cada conjunto de reglas.

Reglas antiguas · Solo PaymentBurn

• 100 USD: aceptado
• Los 50 de Alice redimidos, luego se crearon 50 USD emitidos por alice
• Estado final: gateway posee 50 USD emitidos por alice

Reglas nuevas · Solo PaymentBurn

• 100 USD: rechazado
• 20 USD: aceptado, quedan 30
• 30 USD: aceptado, saldo en cero
• 1 USD: rechazado

Reglas nuevas · PaymentBurn + PaymentMint

• 100 USD: aceptado
• Cruza el cero, ya que la emisión está autorizada y gateway acepta los IOUs de alice

Los Nuevos Tokens Eran la Deuda de Alice

Bajo las reglas antiguas, el pago no añadió unidades de los USD de gateway. La obligación de gateway hacia alice cayó de 50 a cero. Lo que apareció en cambio fue 50 USD emitidos por alice y en poder de gateway: alice terminó la transacción debiendo al emisor, en virtud de un pago firmado por un delegado al que solo había autorizado para rescatar.

El ledger trata esos activos como dos activos distintos. La documentación de formatos de activos de XRPL identifica un token de trustline por su código de divisa y su cuenta emisora, por lo que los USD de alice y los USD de gateway comparten código pero no emisor. El XRP nativo, que no tiene emisor, quedó completamente fuera del fallo.

En el caso documentado, el riesgo recaía entonces en dos partes: la cuenta que delegó la autoridad de quema, que podía asumir un pasivo que nunca aprobó, y el emisor que recibía esos IOUs. Los tenedores de los USD de gateway no enfrentaban nuevas unidades del token que poseían.

La Condición Previa Que Acotó el Fallo

El exceso dependía de una configuración del lado de gateway. Sin una línea de confianza que aceptara los IOUs de alice, el pago no tenía forma de crear USD emitidos por alice. Un emisor debe presentar esa línea de confianza por sí mismo, lo que constituye el argumento más sólido de que el fallo tenía un alcance práctico limitado.

Ese argumento tiene un matiz. La documentación de delegación de XRPL también incluía los Multi-Purpose Tokens (MPTs) entre los activos que un delegado de solo quema podía emitir antes de la corrección, mientras que la prueba del commit cubre solo el caso de la trustline. Ninguna de las fuentes describe un incidente real, pero la lectura de la trustline no debe extenderse a los emisores de MPTs sin una prueba propia.

Un Permiso Aún Cubre Todas las Divisas

La enmienda limita cuánto puede redimir un delegado de solo quema. No modifica qué tokens alcanza el permiso. Los permisos granulares están codificados de forma fija, y la misma documentación indica que una cuenta no puede otorgar a un delegado el derecho a enviar algunas divisas mientras excluye otras.

Para una cuenta de operaciones que posea tokens USD y EUR, o stablecoins de dos emisores, una sola concesión de PaymentBurn permite al delegado redimir todas, cada una hasta su saldo. Cualquier división por divisa debe provenir de cómo se distribuyan las tenencias entre cuentas. El permiso de tipo de transacción Payment llega aún más lejos, cubriendo pagos de ese tipo en general, por lo que una revisión que solo verifique los dos valores granulares puede pasarlo por alto. El artículo anterior de Coindoo sobre cómo XRPL divide la autoridad operativa entre cuentas explica cómo estructuran las instituciones esos roles.

Qué Revelaría Si el Fallo Fue Explotado

Cada concesión es pública. La entrada de ledger Delegate registra la cuenta que otorga, el delegado y su lista de permisos, lo que convierte el uso indebido en una pregunta que cualquiera puede verificar onchain.

El patrón onchain:

• Un pago validado después del 8 de octubre y antes del ledger 108,112,129.
• Firmado por un delegado con PaymentBurn, pero sin PaymentMint ni Payment, en ese momento.
• Enviado al emisor del token, dejando la cuenta delegante con saldo negativo en esa trustline.

Un pago que cumpliera los tres criterios confirmaría que el exceso ocurrió en Mainnet. Una revisión de todas las concesiones PaymentBurn en ese periodo que no encontrara ninguna lo descartaría para los tokens de trustline, con los MPTs como verificación aparte. Como DelegateSet reemplaza la lista de permisos de forma completa, como explicó el informe previo a la activación, la verificación debe usar los permisos vigentes cuando se validó cada pago.

La enmienda aplica desde el ledger 108,112,129 en adelante. Cualquier pago validado antes queda exactamente como fue registrado, incluidos los que cruzaron el cero. Para los operadores que revisen transacciones alrededor del cambio, el número de ledger validado es, por tanto, la frontera relevante para determinar qué reglas se aplicaron.

Fuente: Coindoo