XRP Ledger Narrows Restricted-Token Fix to Two Proposals

XRP Ledger keeps two authorization proposals open

The two surviving pull requests, numbered 8648 and 8650, were opened October 27 and share the proposed amendment name fixCleanup3_5_0. The public repository showed both still open at the November 1 review.

In the closure of proposal 8649, its author said reviewers agreed that issuer authorization governs holding and receiving tokens, while a separate freeze mechanism controls spending. That distinction explains why the package became narrower.

The withdrawn proposal would have made existing unauthorized balances spendable only back to their issuer. Reviewers rejected that broader change to shared balance-handling functions. The current plan therefore should not be described as a blanket return-to-issuer restriction on every existing unauthorized balance.

Developers also closed proposal 8651, which would have added a transaction-wide check for unauthorized balance changes. Its author said the extra protection offered little benefit once the targeted entry checks were in place and would require exceptions for legitimate credits, including issuer clawbacks.

The decisions followed review on October 28. They change the substance of the proposal, not merely its count: the remaining approach focuses on routes that create additional unauthorized exposure rather than rewriting every use of an existing balance.

This is separate from the earlier XRPL emergency server patch. A shared network and similar software terminology do not make the new token-authorization discussion evidence of another emergency or a completed mainnet upgrade.

AMM shares would require both issuers’ approval

Proposal 8648 addresses liquidity-provider tokens, which represent a share of the two assets held in an automated market maker, or AMM. Such pools let users exchange assets against deposited liquidity.

The proposal says approval checks at deposit are insufficient because pool shares can subsequently move between accounts. Someone lacking permission to hold one underlying asset could acquire exposure indirectly through the transferable share.

The proposed gate would check permission for both pool assets when an account acquires the share through payments, offers, NFT offers or an AMM auction bid. It preserves exits such as returning shares to the pool or withdrawing one asset at a time, while leaving issuer clawbacks unchanged.

The practical issue is the difference between owning a restricted asset directly and holding a claim on a pool containing it. An approval system that checks only the first route can leave the second outside its intended boundary.

That distinction becomes relevant when assets such as tokenized fund shares issued on XRP Ledger carry ownership conditions. The proposal does not establish that any particular fund, stablecoin or issuer was affected.

Trust-line receipts face a separate XRPL check

Proposal 8650 targets a payment check that currently applies when an unauthorized trust line has a zero balance. A trust line records a token balance between accounts; an existing nonzero balance can let additional receipts through that check.

The proposed change would stop those receipts and prevent a redemption from crossing zero into a fresh unauthorized position. Returning the outstanding amount to its issuer remains possible. Existing balances remain spendable under the reviewed design, with freezes serving a different purpose.

The official authorized-trust-line documentation says issuers can require approval before accounts hold their tokens. It explicitly excludes native XRP from allow-listing. The issuer must choose this setup before issuing tokens, and authorization is distinct from freezing a holder’s balance.

A dedicated loss-impact check at 13:59 UTC on November 1 found no verified theft total, victim-wallet count, attributable transaction trail or attack wave in the reviewed proposal records and targeted exploitation searches. The findings do not establish a zero-loss audit of every historical balance, and no confirmed financial loss should be inferred from a code-level authorization gap alone.

The proposals still need review and release inclusion. Under the XRPL amendment process, transaction-processing changes require more than 80% support from trusted validators for two weeks before activation. An open pull request does not start that countdown.

Alternative.me’s Fear & Greed Index read 34, or Fear, on November 1, versus 30 a day earlier. It measures broad crypto sentiment rather than validator support or token-authorization exposure.

No activation date or affected-account total was established in the reviewed records. The next concrete milestones are merged code, a software release containing the changes and sustained validator approval, rather than the amendment’s appearance in development discussions.