The XRP Ledger is weighing a bundled bug-fix amendment that would close several gaps in how issuer-restricted tokens behave, including two gaps involving automated market maker liquidity pool tokens and trust lines that carry a non-zero balance at the moment restrictions take effect. The package, filed under the identifier fixCleanup3_5_0, collects four separate corrections into a single amendment rather than advancing them individually.
According to reporting dated to October 30, the amendment had not been merged into the XRP Ledger's reference implementation and had not been activated on the mainnet. That places it in the earliest phase of the ledger's governance pipeline: proposed, discussed, and awaiting both code review and sustained validator approval before it can change state on a live network that custodies tens of billions of dollars in tokenized value.
The fixes are narrow in scope but not in consequence. They sit at the intersection of two trends that have defined XRPL's positioning over the past two years: institutional tokenization, where issuers need enforceable control over who may hold and transfer their assets, and decentralized exchange infrastructure, where those same assets are expected to trade permissionlessly. Every restriction the ledger enforces is also a restriction that decentralized finance primitives must learn to route around.
What "restricted" means on XRPL
XRPL has supported authorized trust lines since its early years through the RequireAuth account flag. When an issuer enables it, no counterparty can hold the issuer's token until the issuer explicitly authorizes that specific trust line. The model is deliberately account-level and explicit: authorization is a state on the trust line, granted and revoked by the issuer, and the ledger enforces it at the point of transfer rather than relying on off-chain allowances or smart contract conventions.
Layered on top of that are freeze mechanics. An issuer can freeze an individual trust line or apply a global freeze across its entire issuance, halting transfers without destroying balances. A related setting, sometimes called deep freeze, blocks a frozen counterparty from sending the asset onward as well as receiving it. Together these tools are what let a regulated issuer answer a subpoena, respond to a sanctions designation, or suspend a compromised counterparty without unwinding the entire token.
The model has held up well for plain transfers between two accounts. It has held up less well where the ledger's own primitives create indirect exposure: a restricted asset deposited into a liquidity pool is no longer held directly by the depositor, and the receipt the depositor receives is a different asset with its own trust line and its own issuer. Each additional layer of representation is a place where an authorization check can be applied inconsistently, or not applied at all.
That is the class of defect the amendment addresses. XRPL's amendment process is intentionally conservative, and fix-type amendments are the mechanism for correcting behavior that was never intended, as distinct from feature amendments that add new capability. A bug fix that changes ledger state still requires the same supermajority as a feature, which is why even unambiguous corrections can take months to reach mainnet.
The liquidity token gap
The first of the two documented fixes concerns AMM LP tokens. On XRPL, a liquidity pool is itself an account, and the pool's share tokens are trust line tokens issued by that account, transferable and balanceable like any other asset. When a holder deposits an issuer-restricted asset into a pool, the holder's direct relationship with the issuer is replaced by a relationship with the pool.
The restriction semantics that the issuer set on its own token do not automatically propagate to the pool's LP token. In practice that creates a path where a party the issuer would not authorize can end up with economic exposure to the restricted asset through a derivative instrument the issuer never issued and cannot directly freeze. The issuer's control surface covers the underlying; it does not obviously cover the receipt.
The reported fix brings LP token trust lines into the same authorization framework, so that holding a pool's shares is subject to checks consistent with the restrictions on the assets inside it. The precise mechanism, whether the pool account enforces authorization at deposit time or the LP token inherits a flag, is not described in the reporting, and no code-level reference was provided. That gap matters: the difference between validating at deposit and validating at transfer determines whether existing positions must be unwound or can be migrated in place.
This is not the first time pooled assets have been the awkward edge of XRPL's compliance tooling. Clawback, introduced in 2024, gave issuers a recall mechanism for balances held by a counterparty, but the interaction between an issuer's recall authority and assets sitting inside a pool has remained a genuinely unsettled question. The pattern is consistent: the ledger's control features were designed for direct holdings, and each new composability primitive creates a new indirect holding that the original design did not anticipate.
The non-zero balance gap
The second documented fix concerns trust lines that already hold a non-zero balance when restriction rules apply. Authorization on XRPL is normally evaluated before a trust line can receive value, but a trust line created and funded before an issuer enabled RequireAuth is in a different state: it exists, it holds tokens, and it was never authorized. The reporting describes this as a residual case the ledger handled inconsistently.
Residual states are where compliance tooling tends to break down. An issuer that switches on authorization expects a clean perimeter, and a trust line that predates the switch is a hole in that perimeter that neither the issuer nor the ledger can resolve without either authorizing the line retroactively or forcing the balance out. Both options require a defined ledger behavior, and the absence of one is precisely the kind of ambiguity that auditors flag and that exchanges later discover during an integration.
The fix is described as completing the semantics so that pre-existing balances are handled by a defined rule rather than an implicit one. What the reporting does not establish is which rule: whether such trust lines become frozen, become transferable only back to the issuer, or become subject to a grace period. Each choice has different consequences for holders who acquired tokens in good faith before the issuer changed its policy, and for issuers who may prefer a clean sweep.
The bundling question
XRPL bundles related corrections into versioned cleanup amendments, and the naming convention signals that this package is scoped to a specific reference implementation release. Bundling has real advantages: it reduces the number of simultaneous activation windows the validator set must track, and it prevents a situation where two interdependent fixes land weeks apart and leave the ledger in a state that neither anticipated.
It also concentrates risk. A single failed review on any one of the four components holds the entire package, and the reporting describes only half the contents. Two named fixes can be reasoned about; two unnamed fixes cannot. For an amendment whose subject is authorization semantics, the unexamined half is not a footnote. It is the part of the change surface that nobody outside the immediate review circle has been able to check.
The absence of a linked specification compounds this. XRPL feature amendments normally have a corresponding standards discussion and a pull request against the reference implementation, and both are publicly reviewable. Neither was cited in the reporting. Without those artifacts, a reader cannot distinguish between a fix that adjusts a validation path and a fix that alters the state machine, and those two possibilities carry very different migration burdens for exchanges, custodians, and bridge operators.
Activation math
Amendments on XRPL activate when a supermajority of validators, conventionally set at eighty percent of trusted validators, signal support continuously for two weeks. The reporting confirms the two-week requirement and confirms that the threshold had not been reached as of the October 30 snapshot. No validator count, current support percentage, or comparable historical activation timeline was disclosed.
Those omissions make activation timing unquantifiable. Two weeks is the floor, not the estimate: the clock resets if support drops below the threshold for any single ledger, and contested amendments have historically sat in a partially supported state for extended periods. An issuer planning to rely on the new restriction semantics cannot schedule a product launch against an unknown activation date, which in practice means the fix will be treated as unavailable until it is live and observed.
For operators, the operational consequence is a version dependency rather than a product decision. Exchanges and custodians that custody restricted XRPL assets will need to upgrade to a server release containing the merged fixes, verify their internal authorization checks against the new behavior, and reconcile any trust lines that the pre-existing balance rule would treat differently. None of that can be scheduled from the information currently public, and all of it is work that will eventually be compressed into whatever window the activation creates.
The disclosure question
The most consequential claim in the reporting is also the least verifiable. XRP Ledger Foundation officials, relayed through a secondary report, stated that no external party had been found to have exploited the gaps. That is a statement about detection, not about possibility. It does not establish that no unauthorized holder exists, only that none has been identified by the party making the statement.
The distinction matters for two audiences. For issuers, an unexploited bug is a maintenance item; an exploited bug is a disclosure event with regulatory consequences. For holders of restricted assets, the relevant question is whether their position will survive the activation of a rule that did not exist when they acquired it. Neither question is answered by a self-reported clean bill of health, and no independent audit or on-chain analysis was cited in support.
There is also a structural reason to expect under-detection here. A gap in authorization semantics is not an exploit that drains a pool or breaks consensus. It is a quiet state that looks normal from every dashboard: a balance is a balance. Finding it requires enumerating restricted issuances, their trust lines, and the pool positions built on top of them, then checking each against the issuer's stated policy. The reporting discloses no such enumeration, and no figures on how many issuers use RequireAuth, how many authorized trust lines exist, or how much value sits in the affected states.
What the reporting leaves open
Strip the analysis down and the public record contains four facts: a four-part amendment exists, two of the parts concern LP tokens and pre-existing balances, the package is unmerged and inactive, and the foundation says it found no exploitation. Everything needed to size the change is missing, including the code, the specification, the validator distribution, the affected population, and any third-party validation. On the evidence available, the correct confidence level for any claim about impact is low, and the correct posture for anyone with exposure is to verify independently rather than rely on the summary.
The verification path is not exotic. It runs through the reference implementation's pull requests, the amendment registry, and the standards repository, and it produces answers to the questions the reporting leaves open: what the other two fixes change, whether activation is close, and whether any restricted issuance currently sits in a state the new rules would treat differently. Those are checkable facts, and they are checkable now rather than after activation.
Why it matters beyond one ledger
The broader significance is that permissioned and permissionless finance are converging on the same infrastructure, and the seams show. Tokenization platforms want issuer control that is enforceable at the protocol level, not negotiated through smart contract conventions. Decentralized exchange primitives want composability, which by construction means that any asset can be wrapped, pooled, and re-represented. The two requirements are in direct tension, and every ledger that hosts both will spend the next several years patching the boundaries between them.
Other ecosystems have approached the same problem from the opposite direction, building permissioned token standards that embed allowlists and transfer restrictions into the asset itself and then requiring every venue to honor them. That approach produces stronger guarantees inside a closed ecosystem and weaker ones at the boundary, where a permissioned asset meets a permissionless pool. XRPL's choice is the mirror image: restrictions live in the base ledger and apply to everyone, so the work is to make each new primitive honor checks it was not designed around.
XRPL's approach, correcting the semantics rather than restricting the primitives, preserves composability at the cost of a heavier governance load. That is a defensible choice, and it is also a slow one. The relevant precedent is not whether this particular amendment is correct, but whether the process that produced it, and the disclosure that accompanied it, is rigorous enough that issuers can build products assuming restrictions will hold. Right now the public record does not support that assumption, not because the fix is wrong, but because so little of it is visible.
What to watch
Three signals will resolve most of the uncertainty. First, whether the amendment appears in the reference implementation's review queue with all four components documented, which would make the change surface auditable. Second, whether validator support crosses the threshold and holds, which converts an abstract timeline into a date. Third, whether any restricted issuer discloses a position affected by the pre-existing balance rule, which would indicate that the gap had real occupants rather than theoretical ones.
Until then, the honest summary is narrow. A ledger with a serious institutional pitch has identified gaps in the controls that pitch depends on, has proposed fixes for at least two of them, and has not yet shipped any of it. The absence of evidence of exploitation is welcome and insufficient.