XRP Ledger activates fix for delegated burn permission

What happened

The XRP Ledger has enabled an amendment called fixCleanup3_4_0, which removes a side effect from PaymentBurn, a permission that issuers can delegate to another account so that account can burn their tokens. The amendment went live on Nov. 4 at 14:52 UTC in ledger 108,112,129, according to the amendment tracker XRPLWin, as reported by Unchained and Blockonomi.

Permission delegation on the XRP Ledger lets one account give another account specific powers without handing over full control. PaymentBurn is meant to let a delegate destroy fungible tokens on an issuer's behalf. Before the fix, XRPL documentation said a delegate holding that permission could also create new fungible tokens in certain circumstances, covering trust-line tokens and Multi-Purpose Tokens. Other granular permissions were not affected, and the native supply of XRP was not involved.

The correction is narrow. According to the xrpld 3.4.0 release notes cited in the reports, the ledger now rejects PaymentBurn transactions that cross a zero balance. The amendment also bundles other repairs, including rounding fixes for Single Asset Vaults, changes to automated market maker clawbacks, escrow reserve fixes, separate signing prefixes for counterparty and sponsor signatures, permissioned trading corrections and accounting fixes for the proposed lending protocol. It does not switch on the lending features themselves.

Why it matters

Issued assets on the XRP Ledger, including stablecoins, can depend on burn permissions for redemption and supply management. A delegate that was supposed to be able to destroy tokens, but could also create them in edge cases, weakened issuer control over supply. For 27 days, delegation was live on mainnet while the burn permission could still create tokens, and the only safeguard was documentation advising issuers not to grant PaymentBurn.

With the amendment active, issuers that want to hand burning duties to a separate account no longer have that caveat attached to the permission. No confirmed exploitation of the flaw has been publicly reported, and the available disclosures do not name any issuer that suffered unauthorized token creation. The fix addresses the zero-balance crossing rather than redesigning the delegation system.

What the data shows

The activation occurred in ledger 108,112,129 at 14:52 UTC on Nov. 4, per XRPLWin. The fix shipped with xrpld 3.4.0, released Sept. 17, but a server release alone does not change transaction rules. Blockonomi reported that the first approval window opened Oct. 9, putting activation on track for around Oct. 23, before support fell on Oct. 21 after 12 days and three hours. A new majority formed later that day, and the second run lasted 14 days and five minutes. With 35 validators on the tracked default list, at least 29 had to back the amendment for the full period.

Background

Delegation went live on the XRP Ledger on Oct. 8, and Unchained reported on Oct. 9 that the burn-permission fix was still short of the validator votes it needed. The amendment first reached a majority on Oct. 9 but lost it on Oct. 21, roughly 12 days into the approval window. Support returned the same day, and the second attempt held for the full 14 days required for activation.

XRPL amendments pass only when more than 80% of trusted validators back them for two straight weeks; a drop below that line restarts the count. The reports also distinguish this fix from a separate payment engine integer overflow that could have affected XRP's fixed supply. That flaw was patched in xrpld 3.4.1 on Sept. 25 without a validator amendment vote, according to the developers' disclosure, while a lower-impact Batch flaw was fixed by the fixBatchV1_2 amendment that activated Oct. 9.

What is still unclear

Public reports do not identify any issuer that may have been affected or confirm whether unauthorized token creation occurred during the period when delegation was live and the burn permission retained the side effect. The disclosures describe the technical condition and the fix but do not provide a public accounting of any issuance anomalies.

What to watch

With the amendment enabled, issuers can now delegate PaymentBurn without the documentation warning that previously advised against granting it. Separate lending amendments, including LendingProtocolV1_1, still need the same validator approval before they can run on mainnet; Blockonomi reported that Ripple has backed the lending amendments, which would let loan brokers arrange fixed-term loans using assets deposited into vaults.

Questions readers ask