Mentioned in This Article
1. XRP Ledger flaw fix set for November 4
The XRP Ledger flaw fix is on track to take effect on Wednesday, November 4, closing a loophole that lets an account create tokens it was only authorized to destroy. Validator support briefly slipped in October, which restarted a two-week activation countdown and delayed the update by nearly two weeks. The native XRP supply is not affected, and the problem concerns tokens issued on the ledger, including stablecoins.
The amendment is named fixCleanup3_4_0. It currently has backing from 33 of the 35 trusted validators tracked by the XRPL Dashboard, comfortably above the level needed to proceed. If support holds, the earliest activation window opens at about 14:46 UTC on November 4.
This article explains what the bug does, why the fix needed a second attempt at the countdown, and which other repairs are bundled with it, including calculations for trading pools, vaults and loans.
For readers outside the XRP community, the episode is a useful look at how a decentralized ledger handles repairs. There is no central release manager who can switch a fix on. Instead, the change travels through a voting process that gives operators of the network time to object, and that process is what set the November 4 date.
2. What is the bug in the XRP Ledger?
Under certain conditions, the flaw lets an account that has permission only to destroy, or burn, an issuer's tokens create new ones instead. Destroying tokens and issuing them are meant to be separate powers, and the ledger is supposed to require distinct permission for the second.
The network's official documentation warns developers not to grant the token-burning permission until the correction takes effect. That advice is a practical safeguard: if an account is never given the burn permission, it cannot exploit the loophole.
The issue applies to tokens issued on the ledger rather than to XRP, the network's native asset. XRP was created in full at the start and is not minted by token issuers, so its supply is outside the scope of the bug.
The flaw is a permissions problem rather than a theft mechanism. It does not let an outsider take funds from other users. Its significance lies in who could be affected: an issuer that has delegated limited powers to a partner, and that relies on the ledger to keep those powers limited. A gap between what the issuer thought it granted and what the ledger enforced is exactly the kind of mismatch that a cleanup amendment is meant to remove.
Because the problem touches tokens issued on the ledger, it is relevant to the growing set of stablecoins and other assets that use the network to move value. The fix keeps the supply controls of those tokens in the hands of their issuers, where the design places them.
3. Why could stablecoin partners print new tokens?
A stablecoin company offers a plain example. It might allow a payments service to destroy tokens whenever customers redeem them for dollars, since redemption means the tokens come out of circulation. That service should need entirely separate permission to issue new tokens, because creating supply is a much more sensitive power than retiring it.
The fix enforces that separation. After it activates, an account holding only the permission to destroy tokens will no longer be able to create them, and the ledger will check the two permissions independently.
The exposure matters for any business that relies on third-party partners to handle redemptions. Granting a partner the ability to burn tokens is a normal and reasonable step in that arrangement. Until the update is live, the loophole means that this routine permission could in theory carry more power than the issuer intended, which is why the documentation urges caution in the meantime.
In the language of the ledger, an issuer is the account that creates a token and stands behind it, while holders are the accounts that receive it. Supply rises when the issuer sends tokens out and falls when tokens return to the issuer. Allowing a partner to destroy tokens is a way of letting redemptions happen without the issuer personally handling each one, and it is a delegation that only works safely if the partner cannot go the other way and add to the supply.
4. How do XRP Ledger amendments get approved?
Changes to the ledger's transaction rules are called amendments, and they are not imposed by any single company. They depend on validators, the independent operators whose computers check transactions and agree on the network's shared history.
An amendment needs support from more than 80% of trusted validators, held without interruption for two weeks. With 35 validators counted, 29 must keep backing the change throughout that period. If support drops below the line even briefly, the clock resets and the two weeks start again.
This design gives the network a strong check against rushed changes. It also means that a short dip in support can have a lasting effect on the timetable, as happened in this case.
The threshold of more than 80% is deliberately high. A large margin of agreement helps make sure that a change is broadly accepted before it alters the rules every participant must follow. At the same time, a requirement of unbroken support means that a validator going offline for maintenance, or briefly changing its vote, can interrupt the process, which is a trade-off the network accepts in return for stability.
Counting matters in a small group. With only 35 validators tracked, losing a handful of votes is enough to fall below the line, because 29 is the minimum. That is why a fall to 26 on October 21 was enough to reset the countdown, even though most validators continued to back the amendment.
5. Why was the fix delayed by nearly two weeks?
The update was originally expected to take effect on October 23. On October 21, support fell to 26 validators, below the 29 needed, and recovered about two hours later. Because the rules require unbroken support, the two-week countdown restarted from the recovery.
The result was a delay of nearly two weeks for a fix that was otherwise ready. The temporary fall did not indicate any new objection to the amendment. It simply shows how sensitive the process is to even a brief lapse in validator participation.
Support has since returned to 33 of 35 validators, and the earliest activation window is now November 4, provided that support holds. The actual switch follows a network voting checkpoint, so the exact timing depends on the ledger's own schedule.
The sequence illustrates why many network operators prefer conservative timetables. A fix that is delayed by two weeks is an inconvenience, but a fix that activates without enough support could split opinion about the ledger's rules. The process favors the slower, safer outcome.
6. What else does the update change?
The package corrects more than the token loophole. It repairs calculations in two areas: issuers recovering tokens from trading pools, and users depositing into or withdrawing from vaults, which are structures that pool assets together.
A separate correction stops a loan from being marked late or in default before its due date has actually passed. The change prevents a borrower from being treated as delinquent too early, which would have given an inaccurate picture of the loan's status.
None of these items alters the supply of XRP. Their common thread is accuracy: each makes the ledger's arithmetic and permission checks match the behavior its designers intended.
Trading pools, sometimes called automated market makers, hold two assets and let users swap between them. When an issuer recovers its own tokens from such a pool, the amounts returned to each party must add up correctly. Vaults work on a similar principle of pooling, and users who deposit or withdraw expect the share of assets they receive to match what they put in. Errors in these calculations would lead to wrong balances, so correcting them ahead of wider use is sensible housekeeping.
7. Where does the XRP Ledger lending service stand?
These lending repairs are arriving before the lending service itself. The service's main amendment has 19 validator votes, according to the XRPL Dashboard, and the vault system it depends on has 21. Neither has reached the 29 votes required to begin its own two-week countdown.
Fixing the loan and vault calculations first reduces the chance that errors in those areas affect users once the lending service goes live. The sequence also shows that the vault system is a prerequisite for lending, so both amendments must advance together.
For now, the lending service lacks enough validator support to launch, and nothing about Wednesday's fix changes that count by itself.
The dependency between the lending service and the vault system is a reminder that new features on the ledger are built in layers. A lending feature needs a way to pool lenders' money, which is the role the vault system plays, and it needs reliable rules for when loans are late or in default. The repairs bundled into this update address that second need before the first feature arrives.
8. What happens next for the network?
The key date is Wednesday, November 4, when the token fix is due to activate if the 29-validator threshold holds through the countdown. Developers who have avoided granting the burn permission can resume normal configurations only after the change is live.
The next milestone is the lending service. If the lending amendment and the vault amendment both reach 29 votes on Wednesday, their countdowns would begin then, and the earliest possible activation of the lending service would be November 18.
Validators and developers will be watching the dashboard counts closely. A second dip in support would restart the clock again, whereas steady backing would let the network complete the fix and move on to the lending features that depend on it.
Whether the lending amendment can gain the extra votes it needs is the main open question after Wednesday. At 19 votes it is ten short of the 29 required, while the vault amendment at 21 is eight short. Those gaps are larger than the two-vote cushion on the token fix, and closing them depends on validator operators deciding that the lending code is ready.