XRPL Deposit Authorization: reserve and fee math from 1 to 10,000 senders

By XORA Research · Reviewed against XRP Ledger Mainnet data and official protocol documentation

TL;DR: XRPL Deposit Authorization makes incoming value permissioned: strangers are blocked, while preauthorized senders can pay normally and the destination can still initiate certain receipt flows. At the Mainnet settings checked on 7 September 2026, each account-based DepositPreauth entry locks 0.2 XRP in owner reserve and costs an assumed 0.00001 XRP to create, so 10,000 standing approvals require 2,000 XRP of reserve but only 0.1 XRP of setup fees.

That split between temporary reserve and permanent fee burn is the key economic fact. DepositAuth itself is just an account flag. The scale cost comes from the persistent allowlist objects, so the number of approved senders matters far more than how many payments each approved sender makes.

What DepositAuth changes

New XRPL accounts can receive XRP from anyone by default. An account enables Deposit Authorization by submitting an AccountSet transaction with SetFlag: 9, the value of asfDepositAuth. Clearing the same flag disables it. One successful flag-setting transaction changes the rule for future incoming transfers but creates no DepositPreauth object by itself.

With the flag enabled, direct Payments from strangers normally fail. The account can permit a source address by sending a DepositPreauth transaction containing that address in Authorize. The approval is one-directional and currency-agnostic: permission from A to B says nothing about B paying A, and it cannot be limited to XRP or one token. A later transaction with Unauthorize removes the approval.

The control is not an absolute “receive nothing” switch. The official Deposit Authorization specification allows the destination to receive by initiating actions such as CheckCash. It also defines rules for EscrowFinish and PaymentChannelClaim. Most importantly, when the destination balance is at or below the base reserve, an unsolicited XRP Payment of no more than the base reserve can still arrive. That escape hatch prevents an account from becoming unable both to pay a fee and to receive enough XRP to transact.

The cost model: sender count, not payment count

Ripple's public Mainnet server_info endpoint at validated ledger 106,823,472 reported a 1 XRP base reserve, a 0.2 XRP incremental reserve, and a 0.00001 XRP base fee on 7 September 2026. The official reserve documentation confirms that Deposit Preauthorizations count toward owner reserve. These settings can change through validator fee voting.

For N account-based approvals, incremental reserve is N × 0.2 XRP. Setup fees under the standard 10-drop assumption are N × 0.00001 XRP. If every approval is eventually revoked, full lifecycle fees are N × 0.00002 XRP. Reserve is temporarily unavailable for ordinary spending; fees are irrevocably destroyed.

The total-reserve column assumes no other reserve-bearing objects. Real accounts may own trust lines, offers, signer lists, escrows, Tickets, or other objects. Multi-signed transactions also cost more: the published minimum is 10 drops multiplied by one plus the number of signatures, before load scaling. Production software should query current reserve and fee values rather than hardcode this dated snapshot.

The original insight: durable relationships are 100 times more reserve-efficient

Compare two services processing 100,000 incoming payments. Service A accepts 1,000 payments from each of 100 long-lived counterparties. Its allowlist needs 100 entries and locks 20 XRP. Service B accepts 10 payments from each of 10,000 counterparties. It needs 10,000 entries and locks 2,000 XRP. The payment count is identical, but Service A uses 100 times less DepositPreauth reserve.

This makes DepositAuth economically natural for known, recurring relationships: institutional settlement partners, approved treasury sources, a fixed payroll funding set, or a custody account with a bounded source list. It is less natural as a permanent account-address allowlist for a large, rotating retail population. A platform can revoke dormant sources and release 0.2 XRP per entry, but each cleanup adds another transaction and the operational burden of proving that the source is truly obsolete.

Operational tradeoffs that the simple formula misses

Transition order matters. XRPL documentation explicitly permits creating preauthorizations before enabling DepositAuth. A safer rollout builds and verifies the required allowlist first, then sets the account flag. Reversing those steps creates a window in which intended senders receive tecNO_PERMISSION.

An address is not an identity. Preauthorization proves that a payment comes from an approved XRPL account, not that the human or organization behind it still satisfies an off-ledger policy. If a partner rotates its sending address, the replacement is a stranger until approved. Operations need a controlled identity check, a mapped source-address inventory, and an audit trail for additions and revocations.

Failed attempts still have consequences. The official tec code reference says a Payment blocked by DepositAuth can return tecNO_PERMISSION. Once included in a validated ledger, a tec failure destroys the submitted fee and consumes the sender's sequence, even though the destination receives no funds. Applications should show the restriction before signing when possible.

Checks must use validated state. The deposit_authorized API method reports whether a source is allowed to pay a destination. Querying a validated ledger prevents decisions based on provisional state. A true result still does not guarantee payment success; balance, trust-line, liquidity, destination-tag, and other transaction rules can fail independently.

DepositAuth versus nearby account controls

RequireDest and DepositAuth solve different problems. Requiring a destination tag helps a shared receiving address route a payment to the correct customer or invoice, but any sender can invent a tag. DepositAuth decides whether that source may deliver value directly at all. Many custodial systems may need both.

DisallowXRP is also different. Official XRPL documentation describes it as advisory: clients should honor it, but the ledger does not enforce it as a hard payment barrier. DepositAuth is enforced by transaction processing, subject to its documented exceptions. Meanwhile, RequireAuth governs who may hold issued trust-line tokens and is not a replacement for controlling incoming value to the account.

Credential-based preauthorization is also available when the applicable Credentials functionality is enabled. It can express a policy around one exact set of accepted on-ledger credentials rather than maintaining only a list of source accounts. That adds credential issuance, acceptance, expiration, and matching semantics, so teams should model it as a separate architecture rather than assume it is a free drop-in substitute.

A practical deployment checklist

1. Inventory every expected source and decide whether address-based approval fits its key-rotation behavior.
2. Calculate reserve headroom as current OwnerCount × reserve_inc_xrp, plus the new entries and a fee buffer.
3. Create and validate preauthorizations before setting asfDepositAuth; test each expected source with validated-state queries.
4. Monitor blocked attempts, stale entries, source-address changes, reserve headroom, and validated transaction results.
5. Revoke obsolete approvals promptly, then confirm the object disappeared and the 0.2 XRP incremental reserve was released.

Put XRP to work, not idle on an exchange

Deposit Authorization is payment-control infrastructure, not a source of XRP yield. XORA's separate offering is up to 22% APY value (15% native XRP yield, treasury-subsidised during a disclosed bootstrap, plus estimated XORA reward value). Returns are variable and never guaranteed, and users should assess custody, liquidity, operational, counterparty, market, and reward-value risks.

xora.finance is where to put your XRP to work, earning up to 22% instead of leaving it idle on an exchange. Model the potential outcome with the XRP yield calculator, read how XRP yield works, and review the security model before depositing an amount appropriate for your risk tolerance.