Key takeaways
- XRPL developers propose issuer-controlled token blocking permissions
- XLS-87 introduces TokenPreauth and TokenBlock transaction types
- Enforcement remains unfinished and mainnet activation unconfirmed
XRP Ledger developers are working on new token authorization and blocking controls that could allow issuers to prevent specific accounts from acquiring their digital assets, introducing another potential compliance feature for institutions building on XRPL.
An October 16 code proposal introduces two transaction types, TokenPreauth and TokenBlock, under the XLS-87 standard. The changes focus on Multi-Purpose Tokens, or MPTs, rather than ordinary XRP transfers.
The proposal remains in draft development. Its current implementation creates and manages permission records but does not yet enforce the restrictions when accounts attempt to acquire tokens.
XRPL Developers Introduce TokenPreauth and TokenBlock
Under the revised XLS-87 specification, token issuers would gain two complementary ways to manage who can hold their assets.
TokenPreauth would let an issuer approve a specific account in advance for an MPT issuance that requires authorization. This could eliminate the need for a separate issuer approval transaction when that account authorizes itself to hold the token.
TokenBlock would work in the opposite direction, allowing an issuer to prohibit a particular account from acquiring its token.
The proposed restrictions extend beyond direct transfers. Future enforcement code is intended to cover token acquisition through payments, decentralized exchange transactions, checks, escrows, automated market makers and vaults.
Importantly, blocking an existing holder would not automatically freeze its current balance. The specification distinguishes preventing additional token acquisition from restricting tokens already held.
The proposal adds another layer to XRPL's developing institutional controls, which include credential-based access to trading and liquidity infrastructure.
Why Token Blocking Matters for Institutional Assets
Banks and tokenized-asset issuers often need more control over who can receive regulated financial instruments than an unrestricted blockchain transfer model provides.
For example, an institution issuing a tokenized security might need to approve eligible investors or prevent designated addresses from acquiring additional holdings.
XLS-87 would give issuers a way to express some of those restrictions directly through ledger entries rather than relying exclusively on application-level checks.
The design also builds on XRPL's existing permission delegation architecture, which supports separating operational responsibilities without sharing an account's master keys.
Under the proposal, issuers could delegate token-management transactions. A particularly narrow permission, TokenBlockCreate, would allow an authorized operator to block accounts without granting the ability to remove those restrictions.
However, these controls would not automatically establish compliance with securities laws or customer-identification requirements. Institutions would still need appropriate onboarding, monitoring and legal safeguards.
XLS-87 Still Needs Enforcement Code and Validator Approval
The October 16 pull request represents only one stage of the implementation.
Developers have separately proposed the necessary ledger entries, while subsequent changes must ensure that blocked accounts cannot bypass restrictions through other token-acquisition mechanisms.
The current code explicitly allows a blocked account to authorize itself because enforcement has not yet been implemented.
That makes XLS-87 different from the approaching October 23 XRPL upgrade, which concerns fixes to existing functionality and has already entered an amendment activation window.
XLS-87 has no confirmed mainnet activation date or completed validator approval process.
Its development also runs alongside separate lending amendments, which remain subject to validator support before their proposed capabilities can become operational.
For investors, the distinction matters because protocol-development activity does not automatically translate into immediate XRP demand.
Nevertheless, XRPL's expanding token infrastructure, including proposed institutional lending and issuer-controlled permissions, points toward a broader effort to accommodate regulated financial applications.
