Separating destruction from creation
The vulnerability stemmed from the way the ledger handled delegated permissions for issued assets. An account could be given authority to destroy tokens, a process commonly used when customers redeem a stablecoin for fiat currency. Under the former rules, however, delegating the PaymentBurn permission could, in certain circumstances, also allow the delegate to mint fungible tokens.
The XRPL documentation explains that this minting possibility existed before the fixCleanup3_4_0 amendment was enabled. The documentation describes the problem as a permission boundary failure rather than a flaw in XRP’s own supply mechanics.
That distinction matters. XRP has a separate, fixed supply, while the XRP Ledger also supports assets created by issuers. Those issued assets can represent stablecoins, tokenized funds, loyalty instruments and other forms of digital value. A weakness affecting issuer permissions could therefore create financial and operational risks even when the network’s native currency remains unaffected.
The practical concern was straightforward. An issuer might authorize a payment processor or another service provider to burn tokens after a customer redeems them. The issuer could withhold permission to create new tokens, preserving a tighter supply-control model. Before fixCleanup3_4_0, that separation was not fully enforced in every circumstance.
Amendment required validator coordination
The xrpld 3.4.0 release notes describe fixCleanup3_4_0 as a bundle of amendment-gated corrections. The release also includes changes related to planned lending and Single Asset Vault features, along with fixes affecting automated market maker pools, permissioned trading and transaction signing.
The amendment status recorded by XRPLWin shows that fixCleanup3_4_0 became enabled at 14:52 UTC on November 4, at ledger 108,112,129. XRPLWin says activation followed a second uninterrupted 14-day period in which the amendment received the required validator support. An earlier attempt in October failed to complete after support fell below the threshold.
That process illustrates how protocol changes on the XRP Ledger depend on more than publishing a software release. Amendments require more than 80% support from trusted validators for 14 consecutive days before they can activate. The delay also shows how validator coordination can affect the timing of a security correction, even after the technical change has been prepared.
The release’s other accounting corrections are relevant to the ledger’s longer-term financial ambitions. Planned lending and vault functions require accurate calculations for deposits, withdrawals and overdue loans. Fixes in those areas are less visible than a token-minting loophole, but they address the accounting foundations needed for on-chain credit and asset management.
No confirmed exploitation reported
No publicly confirmed exploitation of the permission issue has been identified in the supplied reports. The available material documents the vulnerability and the corrective release, but does not establish that an attacker used it to create unauthorized assets.
The XRPL Standards repository cautions users not to delegate the PaymentBurn granular permission until fixCleanup3_4_0 is active. That guidance reflects the project’s documented response to the loophole. No opposing public assessment was identified in the supplied sources, so there is no reported disagreement to balance against that position.
The fix arrives as the XRP Ledger seeks a larger role in institutional digital finance. Banks, stablecoin issuers and tokenized-fund providers need more than transaction speed. They also need permission systems that clearly define who can issue, transfer, freeze or destroy assets.
For developers, the episode is a reminder that delegated authority can become a critical risk boundary when blockchain networks support regulated instruments. For issuers, it reinforces the need to review permissions, validator support and upgrade procedures as part of product operations. The immediate issue appears contained by the amendment, but the broader lesson is ongoing: infrastructure designed for financial assets must make every change in supply explicit, limited and auditable.
Jessica Jones is not a person. No notebook, no deadlines, no face behind the name — just a byline this newsroom publishes under. Here is the production line underneath it, because a name beside a portrait reads like a journalist, and this one is not one.
The models. Writing: gpt-5.6-luna. Out on the live web: gpt-5.6-luna and gpt-5.6-terra. Pictures: gpt-image-1. Swap one in the newsroom and this line swaps with it — it is read off the machines, not typed here.
How a story is made
- Research. The searching model reads around the story, pointed at primary sources — the filing, the post, the repository — rather than at somebody else's write-up of them.
- Writing. The writing model drafts it against what was found, at Jessica Jones's usual length and in Jessica Jones's usual register.
- The loop. A reviewer reads the draft and sends it back with notes. Then reads it again. A piece can go round several times before it leaves the building.
- Enrichment. A quotation has to appear word for word on the page it is taken from. A chart may only use figures that appear in the source it cites. Whatever fails is dropped, and the reason is kept.
- Fact check. A last pass hunts for claims the article makes and its sources do not.
- A human stop. Sensitive subjects are held for a person to read before publication, and a person can kill any of it at any point.
If that sounds less like a newsroom and more like a factory: quite. It is called Press Factory.
This article was generated using AI and published automatically without human pre-publication review.
Read and checked by admin on 11/5/2026
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.