XRP Ledger Fix Sets a Cutoff for Reviewing Delegated Token Burns

When the XRP Ledger burn fix took effect

The XRP Ledger activated fixCleanup3_4_0 on November 4, closing a loophole that could let a delegate holding only burn authority issue a new obligation on the sending account’s behalf. Ledger 108,112,129 recorded the change. Issuers reviewing historical redemptions should include that ledger in their search because the corrected rule first applied to transactions in its successor.

The ledger containing the amendment transaction closed at 14:52 UTC. That gives an issuer a better reference for a review than the date its software team installed an update. The September release notes described the correction, but a server running that release could still process a payment under the earlier rules. The relevant question for a particular redemption is which rules governed the validated ledger containing it.

The distinction matters even within the same minute. XRPL.org specifies that transaction processing uses the amendments enabled in the previous ledger. The successor, ledger 108,112,130, closed one second after the activation record, according to the validated ledger header. A review that stops just before the activation ledger would omit one ledger governed by the old rule. A review based on all of November 4 would sweep in hours of activity under the new one.

Section sources[1][2][3][4][6]

How PaymentBurn could change an issuer’s obligations

Consider a holder returning tokens to the account that issued them. The holder can grant another account, the delegate, permission to process the return on its behalf. The trust line between holder and issuer records their balance. Paying back some or all of what the holder owns reduces the issuer’s obligation. Continuing past zero reverses who owes whom. Whether the destination has agreed to hold the source account’s obligations matters at that point.

The developers’ regression test illustrates the distinction. In their example, Alice owns 50 USD-denominated units issued by a gateway. The gateway has also agreed to hold USD-denominated units issued by Alice. Alice gives Bob burn authority. Under the old rules, Bob can instruct a payment of 100 on Alice’s behalf. The first 50 retire the gateway’s units. The excess creates 50 units owed by Alice to the gateway. Both use the currency code USD, but the debtor has changed. These figures come from a software test, not a mainnet incident.

With the cleanup enabled, the same burn-only instruction fails in the test and Alice retains her original holding. A smaller redemption succeeds, as does a subsequent payment that brings the balance exactly to zero. A separate test gives Bob both mint and burn authority and allows the balance to cross zero when the destination accepts Alice’s units. An investigation therefore needs the full grant. A sign change alone cannot distinguish an authorized issue from a burn-only delegate acting beyond its intended scope. Native XRP is outside this issued-token mechanism.

Section sources[2][3][7][9][10]

Which historical ledgers an issuer should examine

Two validated transactions bound the search. The October 8 transaction in ledger 107,524,865 enabled PermissionDelegationV1_1. The November 4 transaction in ledger 108,112,129 enabled the cleanup. Applying the previous-ledger rule to both records gives a potential review interval of 107,524,866 through 108,112,129, inclusive. This interval is our calculation from the ledger records. It identifies when the combination of delegation and the old burn rule was possible on mainnet.

An issuer can narrow the interval by working from its own redemptions. Identify payments returning the issuer’s units and determine whether the sending holder used a delegate. For a delegated payment, locate the grant from that holder to that delegate. Establish which permissions were in force at the time, including any mint authority. Preserve transaction order where a grant changed in the same ledger as a payment. Looking only at permissions displayed today could miss a short-lived grant that has since been removed.

Also review the issuer’s own outgoing delegated payments where it acted as a holder of another account’s units. The two searches answer different questions. An empty list of grants made by the issuer says nothing about grants made by customers who returned its tokens. Document the account pairs, trust lines and periods examined. An empty result from an incomplete archive deserves a different description from a complete history with no applicable transactions. Neither result requires an estimate based on the issuer’s entire token supply.

Section sources[1][4][5][6][8][9][10]

How to reconcile a delegated redemption

For each candidate payment, keep the transaction hash, ledger index, result, source account, destination, delegate and currency code together. Match the instruction to the grant that applied when it ran. Record who issued the units being retired and whose units the destination agreed to hold. A payment involving the right currency code but a different pair of accounts belongs in a different reconciliation. Likewise, an account signing for itself presents a different question from a second account signing under delegated authority.

Then examine what actually changed in the validated transaction metadata. Record the affected trust line and its balance before and after the payment, keeping the account orientation consistent. A submitted amount expresses an instruction. The resulting balance change is what the reviewer needs to compare with the redemption desk’s records. Preserve a record of failed attempts separately so that an unsuccessful instruction never becomes part of a total for completed redemptions.

Consider a hypothetical desk processing a request to retire a customer’s remaining units. Its internal record should identify the asset, the amount to retire, and the instruction that authorized the desk to act. If the ledger movement merely extinguishes the balance, the reviewer can match that result to the request. If the movement continues past zero, retain the transaction and the surrounding entries for investigation. A mismatch calls for an explanation from the issuer or desk before anyone attributes intent or assigns a financial loss.

A useful exception report distinguishes the number of payments examined from the number that require follow-up. For example, an issuer might identify an in-scope grant but find that the delegate never used it. Another might find payments that it can match to redemption requests, plus one for which the internal instruction is missing. The latter is a gap in the issuer’s records. Classifying it separately from a balance that crossed zero lets the operations team pursue the missing instruction while the ledger analyst investigates the technical condition. Those are two different findings even when they concern the same transaction.

Section sources[2][3][7][10]

What token holders and custodians can verify

A holder can independently locate the activation transaction and see when the protocol changed. Assessing a particular token requires information about its issuer and the counterparties that redeemed it. The most informative disclosure would identify the issuing address, the directions of payment reviewed, the grants examined, and whether the issuer reconciled exceptions. An assurance about a software upgrade alone answers none of those historical questions.

Custodians that handle several tokens can ask for the answer by issuer and asset. Even within one currency, a custodian may hold units issued by several accounts. Where the same provider processed instructions for multiple customers, preserve each source account’s grants separately. If a reviewer finds a balance that reversed direction, name the account that became the debtor. Reporting the amount only as “USD minted” could wrongly attribute issuance to the gateway whose units the holder returned.

Uncertainty remains about historical use. CoinDesk reported on November 5 that no exploitation had been publicly confirmed. That statement has a date and a limited scope. The protocol record establishes the rule change, while a finding about a real redemption requires a specific transaction and supporting records. If an issuer discloses an exception, readers should look for the asset, the balance effect, and the issuer’s account of the instruction before drawing conclusions about customers or reserves.

Section sources[1][2][4][7][10]