• CoinDesk reports the fixCleanup3_4_0 amendment went live on November 4, 2026, closing a flaw in permission delegation.
• The flaw let an account holding the limited PaymentBurn permission mint tokens, not only burn them, under certain conditions.
• It concerns tokens issued on the XRP Ledger, including stablecoins, rather than XRP itself.
• CoinDesk reports no publicly confirmed exploitation; the XRPL documentation advised not delegating PaymentBurn until the amendment was enabled.
• Issuers that delegated PaymentBurn should review those grants and the supply history of the affected tokens.

The XRP Ledger has closed a flaw in how it delegates permissions, one that let an account approved only to burn tokens create them as well. CoinDesk reports that the fixCleanup3_4_0 amendment went live on November 4, 2026. The bug concerns tokens issued on the ledger, including stablecoins, not XRP. No exploitation has been publicly confirmed, which is not the same as confirmed absence.

What the flaw allowed

According to CoinDesk, the flaw sat in the ledger's permission delegation system. An account granted the limited PaymentBurn permission, intended only to destroy tokens, could under certain conditions also mint them. The practical reading is that a permission designed to shrink supply could be used to expand it. CoinDesk does not report that this was done in practice, and the specific conditions are not described in the material reviewed here.

Why issuers carry the exposure

The risk falls on issuers rather than on XRP holders. A stablecoin issuer that delegated burn authority to a custodian, redemption agent or partner would have extended more power than it intended, because the delegate could create liabilities without reserves behind them. For a reserve-backed token, unauthorized supply would erode the one-to-one claim that gives the asset its value. That is a plumbing question about who can alter float, not a price question.

What the documentation advised in the interim

The XRP Ledger documentation's known-amendments page recommends not delegating the PaymentBurn granular permission until fixCleanup3_4_0 is enabled. That guidance gave issuers a mitigation before activation: withhold the grant and the exposure does not arise. It also implies that the risk was confined to accounts that actually received the permission, which makes delegation records the first place an issuer would check.

A second, separate disclosure this autumn

This is distinct from an XRP overflow bug in the payment engine, which the XRPL disclosure report dated October 9 says could have let an attacker create XRP in violation of the ledger's rules. That report says the fix shipped in xrpld 3.4.1 and that no evidence was found of exploitation on any public network. Two disclosed supply-integrity bugs in one season shows the amendment process doing its job but also how much depends on patch cadence.

What to watch next

Issuers on the ledger should audit any PaymentBurn delegations and reconcile token supply against expected issuance, since public non-exploitation reports cannot substitute for their own records. Regulators and auditors assessing stablecoin reserves may ask whether such checks were done. The open questions are whether any delegated accounts used the gap and whether the ledger's maintainers publish a fuller technical account of the conditions involved.