XRP Ledger developers have introduced proposed controls that would allow token issuers to authorize or block specific accounts from acquiring new digital assets on the XRPL blockchain. The planned features are aimed at institutional users seeking stronger compliance mechanisms when issuing or managing digital assets, such as tokenized securities or regulated instruments.
New authorization and blocking proposals
The recent code proposal, published on October 16, outlines two transaction types—TokenPreauth and TokenBlock—under the technical standard XLS-87. These additions focus on Multi-Purpose Tokens (MPTs), which differ from standard XRP transfers by enabling specialized compliance and control features.
TokenPreauth would let an issuer pre-approve individual accounts to hold their tokens, streamlining the process for regulated or whitelisted investors. Conversely, TokenBlock would permit an issuer to block a particular account from acquiring new units of a specific token, enhancing control over asset distribution.
The draft proposal extends these restrictions to a range of on-ledger activities involving tokens, including not only direct transfers, but also decentralized exchange trades, escrows, automated market makers, and vault mechanisms. However, if an account already holds a balance of the blocked token, its current holdings are not automatically frozen; the restrictions only prevent further acquisitions.
XRPL, short for XRP Ledger, is an open-source blockchain network known for its fast settlement and low transaction fees. It is widely used for payments, tokenization, and decentralized finance applications.
Mini dictionary: XLS-87 is a proposed technical standard for the XRP Ledger that introduces enhanced asset-management controls for token issuers, particularly through Multi-Purpose Tokens (MPTs).
These new tools build on the XRPL’s existing permission delegation system, which allows operational responsibilities to be divided without sharing sensitive account credentials. Under XLS-87, issuers could delegate specific token-management actions, such as blocking accounts, to trusted operators while limiting their authority to remove those restrictions.
Efforts to introduce token-level authorization and blocking reflect the growing demand among institutions for compliance-focused features, enabling more controlled asset issuance directly at the ledger level.
Institutional compliance and control
Traditional financial institutions and regulated token issuers often require the ability to restrict who may acquire or hold their digital assets—a capability generally lacking in public blockchains. The ability to preauthorize or block accounts offers a way for issuers to maintain regulatory compliance without relying solely on application-level checks.
For instance, a bank releasing tokenized securities may need to ensure only approved investors can hold or trade those tokens. XLS-87’s approach provides direct mechanisms to handle such scenarios through the ledger rather than exclusively through off-chain or external measures.
Issuers also could delegate these permissions within their organizations, allowing compliance teams or designated operators to manage token access without exposing full account control. The TokenBlockCreate privilege, for example, would let an authorized operator block accounts, but not revoke those blocks.
Importantly, while XLS-87 supports these restrictions, issuers must still conduct investor onboarding, due diligence, and legal compliance outside the ledger for full regulatory adherence.
Path to implementation and next steps
The XLS-87 standard remains under active development, and its current code only records authorizations and blocks without actually enforcing them during token acquisition. Additional enforcement code will be required to ensure blocked accounts cannot obtain restricted tokens, even through indirect mechanisms such as decentralized exchange transactions or automated market makers.
Unlike the upcoming October 23 upgrade to XRPL, which addresses existing functionality, XLS-87 has no set timeline for mainnet activation or validator approval. Validation from participating XRPL nodes will be necessary before the proposed changes become active on the mainnet.
Development of XLS-87 is running alongside other XRPL proposals, such as amendments for institutional lending. These also depend on validator support before going live, reflecting the collaborative nature of protocol evolution on the network.
Many investors and institutional users are monitoring these initiatives for their potential to expand XRPL’s role as a platform for regulated digital financial products, although protocol and code upgrades do not create direct or immediate demand for XRP.
Distinctions between protocol development and immediate on-chain asset demand remain important, as the introduction of new compliance features is primarily directed at future institutional and regulatory use cases.
