The XRP Ledger has patched a bug that let approved token burners mint new tokens, with the fix going live on Wednesday. XRP itself was not affected by either the flaw or the repair, according to the information available.
What the bug allowed
The vulnerability centered on approved token burners — accounts granted permission to destroy tokens on the ledger. Under the bug, those same accounts could create new tokens, a capability that runs against the intended burn-only role. The fix removes that path, closing the gap between what a burner is authorized to do and what the code actually permitted.
Token burners are a routine part of ledger operations, used to remove supply from circulation. The bug didn't alter that basic function. What it did was open a side door: an account trusted to subtract from supply could also add to it. The patch shuts that door.
Why the activation clock was reset
Validator support for the fix reset the activation clock in October. On decentralized ledgers, amendments typically need a threshold of validator votes before they activate, and a reset means the voting window restarted rather than carrying forward earlier support. That push restarted in October and culminated in Wednesday's go-live.
The sequence matters because it shows the fix moved through the ledger's normal amendment process — validators signaling support, the clock running, activation following. No emergency override or unilateral change was involved.
XRP untouched
The native asset XRP was unaffected throughout. The bug lived in the token-burner permission logic, not in the ledger's core asset handling, and the fix likewise left XRP alone. Holders of the asset had no exposure to the flaw or to the repair.
That distinction is worth keeping straight. Headlines about ledger bugs can blur the line between the network's native asset and the tokens issued on top of it. In this case, the two stayed separate from start to finish.
What the patch changes for token issuers
For projects that rely on burners, the practical effect is a narrower permission set. A burner can still burn. It can no longer create. Issuers who had built assumptions around the looser behavior — even inadvertently — will need to confirm their operational flows match the tightened rules.
The fix doesn't touch unrelated ledger functions. It targets the specific permission path that allowed creation, leaving the rest of the amendment's scope confined to that gap.
The open question
What the record doesn't show is how long the bug was live before the fix, or whether any approved burner actually used the creation path while it was open. Those details aren't in the facts available. For now, the ledger's amendment has activated and the burn-only boundary is back in place. Issuers running burners should verify their setup against the new rules before their next burn operation.
