XRP Ledger Token Security Proposals Change After Review
XRP Ledger token security is receiving closer attention as developers work to strengthen restrictions on who can receive issuer-controlled assets. However, the current development record differs materially from reports describing four fixes moving forward together.
The original package was divided into four pull requests associated with fixCleanup3_5_0. At the time of review, GitHub showed two still open and two closed on October 28.
That changes both the scope of the work and its implications for holders. In particular, developers have dropped the proposed blanket restriction that would have limited existing unauthorised balances to redemption with the issuer.
Proposal | Intended change | Reviewed status |
|---|---|---|
#8648 | Require authorisation for both underlying pool assets before acquiring liquidity-pool tokens | Open |
#8650 | Close the existing-balance exception in payment authorisation checks | Open |
#8649 | Restrict spending of unauthorised balances to returning them to the issuer | Closed |
#8651 | Add a broader ledger check enforcing the proposed authorisation restrictions | Closed |
Closed proposals should not be described as completed fixes. Their closure reflects a decision about the approach developers intend to pursue.
What the Two Remaining Fixes Would Do
The liquidity-pool token proposal addresses an indirect route to restricted assets.
A liquidity-provider token represents a claim on assets in an automated market maker’s pool. Checking permissions when someone initially deposits into a pool is insufficient if that pool token can later move to an account lacking approval for an underlying asset.
The proposed change checks the recipient’s authorisation for both pool assets across acquisition routes, including payments, trading offers and certain NFT transactions.
The second proposal concerns a payment check that previously applied only when a trust line’s balance was zero. A line already holding tokens could therefore continue receiving despite lacking authorisation.
The revised proposal would prevent those receipts and stop a redemption from crossing zero into a new unauthorised holding. Its test description preserves the ability to send an existing balance to an authorised holder.
Why Developers Dropped the Redemption-Only Restriction
The closing explanation for proposal #8649 distinguishes authorisation from freezing.
The developer recorded review consensus that RequireAuth governs holding and receiving, while freezing is the mechanism for blocking spending. Under that interpretation, changing shared balance-checking functions to prevent existing balances from being spent was not justified.
Proposal #8651 was also closed. Its closing comment says the additional check offered limited benefit once the remaining entry-point checks were in place, while requiring exceptions for legitimate operations.
This is a substantive revision. Readers should not assume that holders will automatically become restricted to returning tokens to issuers under the current proposals.
These Controls Do Not Restrict Native XRP
XRPL’s official documentation explains that authorised trust lines let issuers approve accounts before those accounts hold their issued tokens.
Such controls can support assets with eligibility requirements, including regulated financial products. The documentation explicitly states that this allow-listing does not apply to XRP.
The distinction matters: an update to issuer-controlled token permissions is not a requirement for ordinary XRP holders to seek an issuer’s approval.
Nor does the development record establish a new theft. CoinDesk reported that the XRP Ledger Foundation described the work as routine protocol hardening and said it knew of no outsider exploiting the remaining exceptions. That is the Foundation’s reported assessment, rather than an independent audit conclusion.
When Could the Changes Become Active?
The two remaining pull requests were open when checked. Their reference to an amendment name does not establish mainnet activation.
XRPL’s documented process requires transaction-processing amendments to receive more than 80% support from trusted validators for two consecutive weeks, following implementation in a software release.
There is no verified activation date for these proposed changes in the reviewed material.
Bitnxt’s earlier coverage of the XRP Ledger amendment countdown reset concerned fixCleanup3_4_0. Its conditional November window must not be applied to this separate fixCleanup3_5_0 work.
Bitnxt’s Take: The Review Outcome Is the Real Story
Our assessment is that the most important development is the narrower design emerging from review.
Permission controls need to prevent unauthorised acquisition without unnecessarily blocking legitimate exits or issuer-led remedies. The remaining proposals focus on specific receipt paths, while the closed proposals show where reviewers rejected broader restrictions.
For issuers and application developers, the useful milestones are the final merged code, release documentation and confirmed amendment activation.
For XRP investors, this remains an infrastructure story. As Bitnxt’s XRP Ledger payment-volume analysis previously highlighted, network developments and token-price demand require separate evidence. These proposals alone do not establish a price catalyst.
