Separate the receiving questions
| Question | Relevant information | What does not answer it |
|---|---|---|
| Is this the intended account? | Current receiving details from its owner or platform | A familiar label in an old address book |
| Does it need a destination tag? | The recipient’s actual deposit instruction | An arbitrary number added to satisfy a form |
| Does it restrict incoming payments? | The account’s Deposit Authorization policy and compatible receiving process | Passing a syntactic address check |
| Was the exchange funded? | The actual ETH deposit outcome | A discussion about the XRP receiver’s policy |
Deposit Authorization is an account policy, not an exchange password
XRPL documentation describes Deposit Authorization as an optional account setting, disabled for new accounts by default. It can restrict incoming payments from senders the recipient has not approved. That is a different control from requiring a destination tag; filling a tag does not grant the sending account permission.
The Payment reference documents the applicable transaction rules and limited exceptions. Do not reduce those rules to “all payments always fail” or use an exception as a way to work around the recipient’s policy. For an exchange payout, the useful question is whether the intended recipient can receive the offered payment through the supported process.
Clarify a restricted recipient before committing the input
- Establish who controls the recipient account
- If it is your own account, inspect its current policy through your wallet’s supported account tools. If a platform manages it, ask that platform about its supported receiving process. Do not assume you can change another party’s account settings because you have its deposit address.
- Describe the exact restriction to support
- Say that the receiving account uses Deposit Authorization, rather than reporting only that the address looks valid. Ask whether the planned payout is compatible before funding ETH. A brand name does not identify a particular on-ledger sending account, so do not invent a preauthorization target.
- Keep changes to security policy deliberate
- This page does not advise switching off a restriction or signing an authorization transaction. If the proposed recipient is unsuitable, resolve the destination through a verified, supported process before making an exchange payment. Do not treat an unexplained wallet signature as a routine address check.
Report the unresolved stage without manufacturing another transfer
Keep the ETH funding event separate from any XRP payout attempt. If an exchange has already been funded, preserve the order reference, the original receiving instruction and any actual payout reference available. Describe the observed error or status without assuming that a failed receiving attempt is already an irreversible account credit.
An address-format error, a missing tag and a policy restriction need different investigations. Provide the facts relevant to the particular issue through the proper support channel. Do not change a receiver policy and send another ETH deposit just to see whether the page updates. Account passwords, private keys and recovery phrases are not payment evidence and should not accompany the reference details.
Questions about restricted XRP recipients
- Does a destination tag authorize an incoming sender?
- It serves a different role. Follow the required tag instruction, but do not treat it as granting permission under a recipient’s Deposit Authorization policy.
- Should I switch off Deposit Authorization to make a payout work?
- This guide does not prescribe changing security settings. Establish a verified receiving process and clarify compatibility before funding the exchange.
- Does an accepted address format prove XRP can arrive?
- It does not establish every account policy or the recipient’s crediting process. Resolve the actual receiving requirements separately from syntax validation.
XRPL receiving rules
Reviewed: