Deposit Authorization
How an XRP Ledger account can restrict who is allowed to send it funds.
The default: anyone can send you XRP
By default, any XRPL account can receive XRP (and, subject to trust lines, issued currencies) from anyone, with no approval required from the recipient. This is the normal, expected behavior for most personal wallets.
Why an account might want to restrict incoming payments
Some accounts — particularly those run by institutions, regulated businesses, or applications with compliance requirements — need finer control over exactly who can send them funds, for reasons such as:
- Preventing unsolicited deposits from unknown or unverified counterparties, for anti-money-laundering (AML) compliance.
- Avoiding a flood of small, unwanted "spam" payments (sometimes used to attach unwanted memos or attempt phishing-adjacent messaging via payment memos).
- Ensuring only pre-vetted counterparties (such as verified customers in a KYC'd relationship) can transact with a given account.
How Deposit Authorization works
An account can enable the Deposit Authorization setting, which blocks incoming payments from any account that hasn't been explicitly pre-authorized. Once enabled, the account maintains an allow-list of specifically authorized sending accounts; payments from anyone not on that list are rejected by the protocol itself, rather than needing the recipient to manually process and potentially return unwanted incoming funds after the fact.
Preauthorization
Adding a specific sender to the allow-list is done via a dedicated DepositPreauth transaction, which the receiving account submits to explicitly authorize a given counterparty address before that counterparty can successfully send it funds.
Relationship to Permissioned Domains
Deposit Authorization operates per-account, based on an explicit allow-list the account owner manages directly. A newer, related feature — Permissioned Domains — takes a different, credential-based approach to restricting participation, useful for scenarios where eligibility should be based on verified attributes (such as "is a KYC'd resident of jurisdiction X") rather than a manually maintained list of specific addresses.
Practical use cases
- A regulated financial institution's XRPL account only accepting funds from other pre-vetted institutional counterparties.
- An application's operational account rejecting deposits from any address not already part of its known, verified user base.
- Reducing exposure to unsolicited "dusting" attacks, where an attacker sends tiny, unwanted amounts (sometimes carrying a phishing-oriented memo) to a large number of addresses.