XRP Ledger developers are reviewing two open proposals that would change how issued-token permissions are checked in payment and liquidity-pool operations. The current public code record shows both proposals were introduced on October 27 and are associated with the planned fixCleanup3_5_0 amendment.
The work is protocol development, not a completed upgrade. It does not mean ordinary XRP transfers now require issuer approval.
Liquidity-pool token authorization
The first proposal, number 8648, would require an account acquiring a liquidity-provider token to satisfy authorization requirements for both assets in the corresponding automated market maker.
A pool token represents a claim connected to the pool’s assets. Checking only the direct deposit route may leave other ways to acquire the same exposure, including a transfer or exchange offer. The proposal seeks consistency across those routes.
That consistency matters for an issuer using permission controls: a restriction needs to hold across the ways an account can obtain exposure, not only at the most obvious entry point.
Existing balances and unauthorized trust lines
The second proposal, number 8650, addresses a payment-engine check that previously applied when an unauthorized trust line had a zero balance. The proposed behavior would prevent an existing unauthorized balance from being increased through further receipts.
The code discussion distinguishes receiving an issuer’s tokens from returning an obligation in the other direction. Preventing a new unauthorized holding need not prevent a legitimate redemption or remediation path.
Two broader proposals linked in the discussion are closed. The current open changes are therefore more reliable than treating an earlier description of four proposed fixes as the final package.
Review precedes activation
The XRP Ledger’s amendment documentation says changes affecting transaction processing must first be included in software and then receive sustained validator support. The stated threshold is more than 80% support for two weeks.
An open pull request has not completed that process. Review can alter the design, a release can include or defer it, and validators can make their own activation decisions. None of those stages should be treated as evidence that a rule is already enforced on mainnet.
For application developers, that means testing proposed behavior separately from production assumptions. An anticipated error response is not necessarily the response a live transaction will receive today.
Scope and integration impact
The proposals concern permissioned issued-token relationships and claims on liquidity pools. They do not turn the native XRP asset into an issuer-controlled token.
For affected integrations, useful preparation includes mapping the paths through which a customer receives a restricted asset and identifying how the application displays authorization failures and redemption options. A technically correct rejection can still confuse users if the interface presents it as an unexplained transaction error.
The development record does not by itself establish that an outside attacker exploited the paths under review. It establishes a proposed tightening of protocol behavior.
The next meaningful milestones are the merged implementation, its inclusion in a release and actual amendment status. Until then, the focus is on improving consistency in permission controls, with the final scope still subject to review.
