# Deposit Authorization

Deposit Authorization is an optional [account](/docs/concepts/accounts) setting in the XRP Ledger. If enabled, Deposit Authorization blocks all transfers from strangers, including transfers of XRP and [tokens](/docs/concepts/tokens). An account with Deposit Authorization can only receive value in two ways:

- From accounts it has [preauthorized](#preauthorization).
- By sending a transaction to receive the funds. For example, an account with Deposit Authorization could finish an [Escrow](/docs/concepts/payment-types/escrow) that was initiated by a stranger.


By default, new accounts have DepositAuth disabled and can receive XRP from anyone.

DepositAuth
## Background

Financial services regulations and licenses may require that a business or entity must know the sender of all transactions it receives. This presents a challenge on a decentralized system like the XRP Ledger where participants are identified by pseudonyms which can be freely generated and the default behavior is for any address to be able to pay any other.

The Deposit Authorization flag introduces an option for those using the XRP Ledger to comply with such regulations without changing the fundamental nature of the decentralized ledger. With Deposit Authorization enabled, an account can only receive funds it explicitly approves by sending a transaction. The owner of an account using Deposit Authorization can perform the due diligence necessary to identify the sender of any funds *before* sending the transaction that causes the account to receive the money.

When you have Deposit Authorization enabled, you can receive money from [Checks](/resources/known-amendments#checks), [Escrow](/docs/concepts/payment-types/escrow), and [Payment Channels](/resources/known-amendments#paychan). In these transactions' "two-step" model, first the source sends a transaction to authorize sending funds, then the destination sends a transaction to authorize receiving those funds.

To receive money from [Payment transactions](/docs/references/protocol/transactions/types/payment) when you have Deposit Authorization enabled, you must [preauthorize](#preauthorization) the senders of those Payments.

## Recommended Usage

To get the full effect of Deposit Authorization, Ripple recommends also doing the following:

- Always maintain an XRP balance higher than the minimum [reserve requirement](/docs/concepts/accounts/reserves).
- Keep the Default Ripple flag in its default (disabled) state. Do not enable [rippling](/docs/concepts/tokens/fungible-tokens/rippling) on any trust lines. When sending [TrustSet transactions](/docs/references/protocol/transactions/types/trustset), always use the [`tfSetNoRipple` flag](/docs/references/protocol/transactions/types/trustset).
- Do not place [Offers](/docs/references/protocol/transactions/types/offercreate). It is impossible to know in advance which matching offers will be consumed to execute such a trade.


## Precise Semantics

An account with Deposit Authorization enabled:

- **Cannot** be the destination of [Payment transactions](/docs/references/protocol/transactions/types/payment), with **the following exceptions**:
  - If the destination has [preauthorized](#preauthorization) the sender of the Payment.
  - If the account's XRP balance is equal to or below the minimum account [reserve requirement](/docs/concepts/accounts/reserves), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 1 XRP). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case.
- Can receive XRP from [PaymentChannelClaim transactions](/docs/references/protocol/transactions/types/paymentchannelclaim) **only in the following cases**:
  - The sender of the PaymentChannelClaim transaction is the destination of the payment channel.
  - The destination of the PaymentChannelClaim transaction has [preauthorized](#preauthorization) the sender of the PaymentChannelClaim.
- Can receive XRP from [EscrowFinish transactions](/docs/references/protocol/transactions/types/escrowfinish) **only in the following cases**:
  - The sender of the EscrowFinish transaction is the destination of the escrow.
  - The destination of the EscrowFinish transaction has [preauthorized](#preauthorization) the sender of the EscrowFinish.
- **Can** receive XRP or tokens by sending a [CheckCash](/docs/references/protocol/transactions/types/checkcash) transaction.
- **Can** receive XRP or tokens by sending [OfferCreate transactions](/docs/references/protocol/transactions/types/offercreate).
  - If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the rest of the ordered XRP or token later when the offer is consumed by other accounts' [Payment](/docs/references/protocol/transactions/types/payment) and [OfferCreate](/docs/references/protocol/transactions/types/offercreate) transactions.
- If the account has created any trust lines without the [No Ripple flag](/docs/concepts/tokens/fungible-tokens/rippling) enabled, or has enabled the Default Ripple flag and issued any currency, the account **can** receive the tokens of those trust lines in [Payment transactions](/docs/references/protocol/transactions/types/payment) as a result of rippling. It cannot be the destination of those transactions.
- In general, an account in the XRP Ledger **cannot** receive any non-XRP currencies in the XRP Ledger as long as all of the following are true. (This rule is not specific to the DepositAuth flag.)
  - The account has not created any trust lines with a nonzero limit.
  - The account has not issued tokens on trust lines created by others.
  - The account has not placed any offers.


The following table summarizes whether a transaction type can deposit money with DepositAuth enabled or disabled:

table
thead
tr
th
th
DepositAuth Disabled
th
th
DepositAuth Enabled
tr
th
Transaction Type
th
Sent by Destination
th
Sent by Others
th
th
Sent by Destination
th
Sent by Others
th
Sent by Preauthorized Others
tbody
tr
td
AccountSet
td
(This transaction type never sends money.)
tr
td
CheckCancel
td
(This transaction type never sends money.)
tr
td
CheckCash
td
OK
td
No Permission
td
td
OK
td
No Permission
td
No Permission
tr
td
CheckCreate
td
(This transaction type never sends money.)
tr
td
EscrowCancel
td
Can return XRP from an expired escrow
tr
td
EscrowCreate
td
(This transaction type can only debit XRP, not credit it.)
tr
td
EscrowFinish
td
OK
td
OK
td
td
OK
td
No Permission
td
OK
tr
td
OfferCancel
td
This transaction type never sends money.
tr
td
OfferCreate
td
OK
td
Only if account previously created a matching offer
td
td
OK
td
Only if account previously created a matching offer
td
Only if account previously created a matching offer
tr
td
Payment 
div
(If account has more than the minimum XRP reserve, enables No Ripple on all trust lines, and places no offers)
td
Cross-currency only
td
OK
td
td
Cross-currency only 
sup
1
td
No Permission
td
OK
tr
td
Payment 
div
(If account XRP balance is below the minimum XRP reserve)
td
Cross-currency only
td
OK
td
td
Cross-currency only 
sup
1
td
XRP payments up to the minimum reserve
td
OK
tr
td
Payment 
div
(If account has any trust lines with No Ripple disabled)
td
Cross-currency only
td
OK
td
td
Cross-currency only 
sup
1
td
Balance changes from rippling
td
OK
tr
td
Payment 
div
(If account has placed offers)
td
Cross-currency only
td
OK
td
td
Cross-currency only 
sup
1
td
Balance changes from executing offers
td
OK
tr
td
PaymentChannelClaim
td
OK
td
OK
td
td
OK
td
No Permission
td
OK
tr
td
PaymentChannelCreate
td
(This transaction type can only debit XRP, not credit it.)
tr
td
PaymentChannelFund
td
Can return XRP when closing a channel created by self
tr
td
SetRegularKey
td
(This transaction type never sends money.)
tr
td
SignerListSet
td
(This transaction type never sends money.)
tr
td
TrustSet
td
(This transaction type never sends money.)
p
sup
1
: The DepositPreauth amendment fixes a bug in DepositAuth which causes cross-currency payments to oneself to fail if the account requires deposit authorization. If the DepositPreauth amendment is not enabled, these cases result in "No Permission" instead.
style

.depauth-txtype {
  font-weight: bold;
}
.depauth-status {
  text-align: center;
}
.depauth-na {
  background-color: var(--gray-dark);
  color: var(--white);
}
.depauth-ok {
  background-color: var(--success);
  color: black;
}
.depauth-no {
  background-color: var(--danger);
  color: black;
}
.depauth-maybe {
  background-color: var(--warning);
  color: black;
}
.depauth-subtype {
  font-weight: normal;
  font-size: 8pt;
}
.depauth-spacer {
  background-color: var(--secondary);
  padding: 2px !important;
  font-size: 2px;
  border: 1px solid var(--secondary);
}

## Enabling or Disabling Deposit Authorization

An account can enable deposit authorization by sending an [AccountSet transaction](/docs/references/protocol/transactions/types/accountset) with the `SetFlag` field set to the `asfDepositAuth` value (9). The account can disable deposit authorization by sending an [AccountSet transaction](/docs/references/protocol/transactions/types/accountset) with the `ClearFlag` field set to the `asfDepositAuth` value (9). For more information on AccountSet flags, see [AccountSet flags](/docs/references/protocol/transactions/types/accountset).

## Checking Whether an Account Has DepositAuth Enabled

To see whether an account has Deposit Authorization enabled, use the [account_info method](/docs/references/http-websocket-apis/public-api-methods/account-methods/account_info) to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](/docs/references/protocol/ledger-data/ledger-entry-types/accountroot).

If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (`0x01000000`) is nonzero, then the account has DepositAuth enabled. If the result is zero, then the account has DepositAuth disabled.

## Preauthorization

Accounts with DepositAuth enabled can *preauthorize* certain senders, to allow payments from those senders to succeed even with DepositAuth enabled. This allows specific senders to send funds directly without the receiver taking action on each transaction individually. Preauthorization is not required to use DepositAuth, but can make certain operations more convenient.

Preauthorization is currency-agnostic. You cannot preauthorize accounts for specific currencies only.

To preauthorize a particular sender, send a [DepositPreauth transaction](/docs/references/protocol/transactions/types/depositpreauth) with the address of another account to preauthorize in the `Authorize` field. To revoke preauthorization, provide the other account's address in the `Unauthorize` field instead. Specify your own address in the `Account` field as usual. You can preauthorize or unauthorize accounts even if you do not currently have DepositAuth enabled; the preauthorization status you set for other accounts is saved, but has no effect unless you enable DepositAuth. An account cannot preauthorize itself. Preauthorizations are one-directional, and have no effect on payments going the opposite direction.

Preauthorizing another account adds a [DepositPreauth object](/docs/references/protocol/ledger-data/ledger-entry-types/depositpreauth) to the ledger, which increases the [owner reserve](/docs/concepts/accounts/reserves#owner-reserves) of the account providing the authorization. If the account revokes this preauthorization, doing so removes the object and decreases the owner reserve.

After the DepositPreauth transaction has been processed, the authorized account can send funds to your account, even if you have DepositAuth enabled, using any of the following transaction types:

- [Payment](/docs/references/protocol/transactions/types/payment)
- [EscrowFinish](/docs/references/protocol/transactions/types/escrowfinish)
- [PaymentChannelClaim](/docs/references/protocol/transactions/types/paymentchannelclaim)


Preauthorization has no effect on the other ways to send money to an account with DepositAuth enabled. See [Precise Semantics](#precise-semantics) for the exact rules.

DepositPreauth
### Checking for Authorization

You can use the [deposit_authorized method](/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/deposit_authorized) to see if an account is authorized to deposit to another account. This method checks two things: 

- Whether the destination account requires Deposit Authorization. (If it does not require authorization, then all source accounts are considered authorized.)
- Whether the source account is preauthorized to send money to the destination.


## See Also

- The [DepositPreauth transaction](/docs/references/protocol/transactions/types/depositpreauth) reference.
- The [DepositPreauth ledger object type](/docs/references/protocol/ledger-data/ledger-entry-types/depositpreauth).
- The [deposit_authorized method](/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/deposit_authorized) of the [`rippled` API](/docs/references/http-websocket-apis).
- The [Authorized Trust Lines](/docs/concepts/tokens/fungible-tokens/authorized-trust-lines) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account.
- The `DisallowXRP` flag indicates that an account should not receive XRP. This is a softer protection than Deposit Authorization, and is not enforced by the XRP Ledger. (Client applications should honor this flag or at least warn about it.)
- The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](/docs/concepts/transactions/source-and-destination-tags). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags.
- [Partial Payments](/docs/concepts/payment-types/partial-payments) provide a way for accounts to return unwanted payments while subtracting [transfer fees](/docs/concepts/tokens/fungible-tokens/transfer-fees) and exchange rates from the amount delivered instead of adding them to the amount sent.