XRP Ledger developers are reviewing two protocol changes designed to close remaining paths through which accounts can acquire exposure to issuer-restricted tokens without the required authorization. The open AMM authorization proposal and trust-line fix are intended to ship under the planned fixCleanup3_5_0 amendment. Neither proposal has been merged into rippled or activated on XRP Ledger mainnet, making the work a pending protocol hardening effort rather than a live rule change.
XRPL’s RequireAuth setting allows an issuer to require explicit authorization before another account holds its issued asset. The current gaps concern edge cases where that approval model can be bypassed despite the issuer having enabled authorization controls. The changes are particularly relevant as regulated digital assets become more prominent across blockchain infrastructure, including the expanding institutional framework surrounding RLUSD, although RequireAuth should not be assumed to apply to every stablecoin or tokenized product.
AMM Tokens Can Create Indirect Asset Exposure
PR #8648 addresses a gap involving automated market maker LP tokens. An LP token represents a claim on both assets deposited in its underlying pool, yet it can also be transferred independently. An account that was never authorized for one restricted pool asset could therefore obtain economic exposure by receiving the LP token through a payment, offer, NFT trade or AMM auction refund. The proposal would require authorization for both underlying assets whenever an account acquires the corresponding LP token.
The checks would cover payments, order-book offers, NFT offers, AMMBid transactions and relevant AMM deposits. Importantly, the proposal continues allowing holders to divest their LP positions, including returning LP tokens to the AMM or withdrawing assets under permitted paths. The objective is to stop unauthorized acquisition rather than trap existing holders inside a restricted position.
Existing Trust Lines Would Stop Accumulating More
PR #8650 addresses a separate payment-engine exception. The existing authorization gate only triggered when a trust line’s balance was exactly zero, meaning a line that already carried an unauthorized balance could continue receiving additional tokens. Under fixCleanup3_5_0, an unauthorized trust line would be prevented from increasing that position, with affected payment paths failing once they attempt to deliver additional restricted issuance.
The current design is narrower than an earlier proposal that would have allowed unauthorized balances to move only back to their issuer. That broader approach was abandoned during review. Existing unauthorized balances would remain spendable where current freeze and authorization rules permit, while the new checks prevent those balances from growing through additional receipts. An issuer can also authorize a trust line later, restoring its ability to receive the asset normally.
The changes arrive as financial infrastructure increasingly combines tokenization with explicit ownership and compliance controls. DTCC’s regulated tokenization service similarly preserves legal and transfer restrictions around digital securities, while Ripple’s national trust-bank approval expands regulated infrastructure around custody and stablecoin reserves. XRPL’s proposed fixes address the protocol-level side of that same broader requirement: authorization rules must continue working consistently as assets interact with increasingly complex ledger features.
No activation date has been set. After review, the code must first enter a software release before validator voting can make the amendment effective. XRPL amendments require support from more than 80% of trusted validators continuously for two weeks before activation, and any drop below that threshold resets the timer. Until that process occurs, the current authorization rules remain unchanged.
