XRP Ledger set to fix flaw that let burn rights mint new tokens

The XRP Ledger is about to close a flaw that let an account allowed only to destroy tokens create new ones instead. A fix can switch on no earlier than 14:46 UTC on November 4, 2026. There is no public sign it was ever used.

That warning sits in the XRP Ledger's own developer documentation, which tells builders not to hand out the permission involved until the patch goes live. The crypto outlet CoinGape reported the planned fix on November 2. An amendment tracker run by XRPLWin shows it backed by 33 of the network's 35 trusted validators, about 94 percent.

What the flaw actually does

Issuers on the XRP Ledger can hand narrow powers to other accounts, the way a company gives staff keys to some rooms and not others. One such power, called PaymentMint, lets a helper account create new tokens. A separate one, PaymentBurn, lets a helper destroy them, down to a zero balance and no further. In normal use, the two stay apart.

They did not always stay apart. Under certain conditions, an account handed only PaymentBurn could also mint fresh fungible tokens, the documentation states. A loophole, in plain terms. Picture a shop clerk allowed only to shred old receipts who could also run off new banknotes. That is the bug.

The worry with any unapproved mint is dilution. If extra units of a dollar-backed token appear with no reserves behind them, each existing unit is quietly worth a little less than its holder assumes. That is the outcome a supply cap exists to prevent. It is why issuers guard the mint function so closely.

Affected tokens are the ones projects issue on the ledger, including trust line tokens and the newer multi-purpose tokens. Stablecoins sit squarely in that group. Nothing in the documentation says the gap was ever used. It states only that it existed, and that builders should avoid the risky setup until the repair is on.

Why an issuer would share these powers at all

This setup is not exotic. Stablecoin issuers and other token projects often lean on outside partners for day-to-day plumbing. A payment processor might handle redemptions, burning a user's tokens the moment they cash out for dollars. To do that cleanly, the issuer delegates a burn power rather than signing every transaction by hand.

That convenience is the point of granular permissions. It is also where the danger lived. A partner trusted to take tokens out of circulation should never be able to put new ones in. Whether XRP is itself a stablecoin is a common mix-up, and the answer is no, though the ledger does host many dollar-pegged tokens that work this way. For them, control over supply is the entire product.

Who feels this most are the teams running regulated or dollar-pegged tokens, where a clean audit trail is the selling point. A bank issuing a tokenized deposit, or a firm backing a stablecoin one-to-one with reserves, lives or dies on the claim that supply matches backing. For a memecoin with no such promise, an extra mint is a nuisance. For a regulated issuer, it is the kind of gap that invites an awkward call from a supervisor.

Why XRP itself is not at risk

XRP, the ledger's native coin, does not run on this permission system. Its supply was set at 100 billion units when the network went live in 2012, and no minting function can add to it. So the flaw never touched XRP itself.

What it touched was trust. Issued tokens hold value only because the people using them believe the issuer controls how many exist. A hidden path to mint around that control chips at the one promise those tokens are built on. These public records are designed to be tamper evident, so an abuse would likely leave a trail, and none has come to light.

The vote that still has to hold

Changes to the XRP Ledger do not ship on a developer's say-so. They pass through amendments, which need backing from more than 80 percent of trusted validators, held for 14 straight days, before they turn on. Trusted validators are the independent servers that node operators choose to rely on, and no single company controls the full set.

This fix, bundled in an amendment labeled fixCleanup3_4_0, has had a bumpy run at that bar. It first aimed for an October 23 activation. Support slid to 26 validators on October 21, which tripped the 14-day counter back to zero. The clock restarted that same afternoon, at 14:46:22 UTC, so the earliest it can now switch on is exactly two weeks later.

Beyond the mint fix, the amendment folds in smaller repairs, to vault calculations and to loan records that flagged payments as overdue too early. Larger features sit further back. A full lending protocol and a single-asset vault are separate amendments that stood at 19 and 21 validator votes in early November, short of the gate, so their own 14-day clocks have not started.

What to watch

Watch the validator count. Between now and Wednesday, 33 of 35 gives the amendment headroom, but a single dip below the line would reset the countdown, as October already showed.

This is not the ledger's first supply scare this fall. Reporting flagged a separate problem in September tied to the network's payments engine, which developers have said is unrelated to this one. That earlier bug involved XRP itself. This one involves the tokens built on top of it.

No one has said whether any issuer actually delegated the PaymentBurn power, or whether anyone used the flaw to mint even one token. The documentation treats the step as a precaution, telling builders to avoid the risky setup until the fix is on. Read that as the working picture, not a sealed verdict. An open ledger that has surfaced no abuse is reassuring. It is not the same as proof.