XRP Ledger: two proposed fixes tighten authorization for restricted tokens

Authorization must follow a pool's assets

XRP Ledger developers are reviewing changes intended to enforce authorization requirements imposed by issuers of certain tokens more consistently. Two open change requests in the rippled repository, numbered 8648 and 8650, address paths through which an account could receive exposure without the expected permission. The issue resurfaced in news coverage on October 30, 2026, but its technical documents predate that coverage. This is proposed, discussed code, not an announcement establishing that a new rule is already active on mainnet.

The first change concerns tokens representing a share in an automated pool. Such a holding provides exposure to both pool assets. Checks during an initial deposit are insufficient if the participation token can later change holders through other paths. The text describes payments, offers and certain refunds, among other cases. The proposed fix seeks to require authorization for both assets when an account acquires the participation token, rather than only when it directly supplies liquidity.

An existing position should not bypass the check

The second change addresses another case: in the described path, a payment authorization check triggered only when the trust line's balance was exactly zero. An account already holding a balance could receive more without satisfying the expected rule. The proposed fix seeks to close this exception. This concerns issued assets subject to restrictions; it does not mean every native XRP payment must now be approved by a token issuer.

Both changes are presented under the technical amendment name fixCleanup3_5_0. The repository explains that the original proposal was split to facilitate review. Two additional layers concerning balance handling and a consistency rule were closed after review. Describing the issue as four requests that are all still open would therefore not match the state in the primary documents consulted. Closure must itself be interpreted in the review context, without automatically equating it with production deployment.

Proposal, integration and activation are separate stages

A change request's status indicates progress toward integration into the software. By itself, it does not establish how the network used by holders behaves. An accepted change still needs to follow the applicable deployment and activation process. The examined texts therefore do not justify asking readers to treat these checks as already universal. Documenting an effective change will require connecting the accepted code, distributed version and actual amendment status.

For applications using restricted assets, the issue is consistency of authorization across different operations. The intended effects concern acquiring exposure and receiving additional balances, while exit cases are handled separately in the proposals. The work's existence alone is not proof of theft or harmed users. A useful reading focuses on the technical paths being corrected and their verified status, without turning proposed hardening into a confirmed incident or a rule already in force.