Does Ledger Nano S Accept XRP? Setup, Reserve and Tags

The setup, briefly

Install the XRP application on the device through the manager, then add the account in the
desktop or mobile companion software. The device holds the key and signs; the companion
application reads the ledger and builds transactions. Nothing unusual so far. This is the same pattern as any other asset on the device.

What is unusual is what happens next, and both surprises come from the XRP ledger rather than
from the hardware. Neither is a fault, both are documented, and both are routinely discovered
after a transfer rather than before.

Device role

Holds the key

Account reserve

Required to activate

Destination tag

Only for shared addresses

Balance lives

On the ledger

The reserve, which is why the balance looks wrong

An XRP address does not exist on the ledger until a minimum amount is deposited into it. That
amount is locked as a reserve for as long as the account exists and cannot be spent, which
means a first transfer smaller than the reserve does not activate the account and does not
arrive.

From the user’s side this presents as a transfer that seems to have vanished, or an address
showing zero after a deposit was sent. It is neither a hardware problem nor a lost transfer; it
is a rejected activation, and the fix is to send an amount that clears the reserve.

Destination tags, in the direction people forget

Exchanges receive XRP for thousands of customers at one address and separate deposits by a
numeric destination tag. Sending to an exchange without the tag means the funds arrive at the
exchange and are not attributed to your account.

Coming the other way, from exchange to your own device, no tag is needed, because your address is
yours alone. This asymmetry is the source of the confusion: people learn the tag rule while
withdrawing to a wallet, conclude it is always required, and then send back to an exchange
without one because the field was optional in their wallet software.

Why XRP behaves differently at all

The reserve exists to stop the ledger being filled with empty accounts. Creating an account
costs storage on every machine running the network, so a minimum balance makes spam expensive.
It is a design decision with a clear rationale, and it is the one that surprises people
arriving from chains where an address costs nothing to create.

Destination tags exist for a related reason: the ledger has no notion of sub-accounts, so a
business receiving on behalf of many customers needs a field to separate them. Both quirks come from the same place: a ledger optimised for settlement between institutions rather than
for individuals holding their own keys.

Deleting the app does not delete the account

Storage on the original device is limited, and the usual response is to remove one asset’s
application to make room for another. This alarms people the first time, and the reassurance is
worth stating precisely rather than generally.

The application is an interface, not a container. Keys are derived from the recovery phrase held
by the device, so removing an application removes the ability to view and sign for that asset
until it is reinstalled, and nothing else. The account continues to exist on the ledger with
the same balance, and reinstalling restores access without any recovery procedure.

One consequence is specific to this asset and catches people out. Because the account reserve
has to stay funded for the address to exist, an account emptied to the reserve is not closed and
the reserve is not lost. It is held while the account remains, and it becomes spendable again
only if the account is deleted through the protocol’s own procedure. Anyone who removed the
application and later found a balance smaller than expected is usually looking at the reserve
rather than at a missing payment.

Checking before you send, once

Two questions, answered on the receiving side. Does this address already exist on the ledger,
and does the recipient require a tag. Your wallet or the exchange’s deposit page answers both,
and reading them takes less time than a single failed transfer costs.

After the first successful transfer in each direction, neither question comes up again for the
same pair of endpoints. The whole problem lives in the first transaction, which is exactly why
a small test amount is worth the fee.