An amendment to the XRP Ledger, activated on November 4, removes an unintended feature in the PaymentBurn permission that previously allowed certain delegates to mint tokens, not just destroy them. The fix, called fixCleanup3_4_0, was approved and went live in ledger 108,112,129 at 14:52 UTC, as recorded by amendment tracker XRPLWin.
Amendment details and technical corrections
fixCleanup3_4_0 shipped with xrpld 3.4.0, the latest version of the XRP Ledger’s codebase, released on September 17. The change specifically targets the PaymentBurn permission, which lets one XRPL account delegate the burning of its issued tokens to another account. Until now, the XRP Ledger’s documentation acknowledged that this delegated power could, under certain circumstances, also enable the delegate to create new fungible tokens—even though the permission was intended solely for burning assets.
The new amendment simply rejects any PaymentBurn payment that results in a balance crossing zero, preventing delegates from minting new trust line or multi-purpose tokens (MPTs) with this permission. This restriction does not impact the core XRP supply or other more granular XRPL permissions.
Mini dictionary: Multi-purpose tokens (MPTs) are customizable tokens created on the XRP Ledger, designed for varied use cases underpinning applications and services beyond simple transactions.
Before the fix, XRPL documentation advised caution and recommended that issuers avoid delegating PaymentBurn due to the risk of token creation by third parties.
Additional ledger improvements
This amendment introduced further technical adjustments, including rounding fixes for Single Asset Vaults, updates to Automated Market Maker (AMM) clawbacks, escrow reserve corrections, and the introduction of separate signing prefixes for counterparty and sponsor signatures. These measures aim to improve the reliability and security of operations across the ledger.
Adoption and activation process
XRPL amendments require support from over 80% of trusted validators for two consecutive weeks. XRPLWin data indicates that fixCleanup3_4_0 first achieved majority backing on October 9 but briefly lost validator support on October 21. Support returned the same day, and the two-week window was fulfilled without further interruption.
| Event | Date | Validator Support Status |
|---|---|---|
| First majority reached | October 9 | Above 80% |
| Lost majority | October 21 | Below 80% |
| Majority regained | October 21 | Above 80% |
| Amendment activated | November 4 | Enabled |
During a 27-day period, from the start of delegation on October 8 until activation of the amendment, mainnet delegation was possible, and delegates with PaymentBurn permission could still inadvertently create new tokens. The only safeguard was a warning in the documentation discouraging issuers from granting this permission. With fixCleanup3_4_0 now live, issuers can grant burning rights to other accounts without the previous risk associated with token creation.
For nearly a month, the PaymentBurn permission granted to delegated accounts presented a risk of unintended token creation, mitigated only by a documentation warning. With the activation of fixCleanup3_4_0, this issue has been formally resolved through consensus, and issuers can confidently delegate burning duties.
