Bridge Tokens to an Unactivated XRP Ledger Account

On the XRP Ledger, an address becomes an account only when a Payment credits enough XRP to create its AccountRoot entry. A token bridge transfer alone cannot create that account: the destination needs XRP to meet the network’s base reserve, or the bridge must provide an account-creation path that does so.

What does account activation mean on the XRP Ledger?

Activation means creating an account entry in the ledger by funding a valid address with enough XRP. There is no separate “activate” transaction. The first XRP Payment creates the account, and the account’s keys determine who can authorize later transactions.

The reserve is a balance requirement, not a fee paid to a bridge. The current XRP Ledger mainnet base reserve is 1 XRP, and that amount remains part of the account balance but cannot ordinarily be spent while it is reserved. The reserve can change, so check the live requirement before sending. Other networks can have different reserve settings.

This distinction matters when a bridge delivers a token issued on the XRP Ledger. That token is represented by a trust line between the recipient and the issuer; the trust line is a ledger object, not a balance that can create the recipient’s account. A new recipient therefore needs an account first, then the required trust line, then the token delivery.

Can a bridge activate the destination account?

Only if its destination flow can fund or create the XRP Ledger account. Many bridges move an asset between existing token contracts. They do not automatically send XRP to an uncreated XRPL address, and a transfer marked complete on the source chain does not prove that the destination account was created.

Before signing, check that the bridge supports the XRP Ledger as a destination, supports the specific asset representation, and states how it handles a new recipient. Look for an explicit XRP funding or account-creation step. If the interface asks only for a destination address and token amount, do not assume it will also supply the reserve or create a trust line.

Bridge tracking answers a different question: where a transfer is in its cross-chain process. A separate guide to tracking a Polygon Bridge transfer from source submission to destination delivery covers that path in more detail. For an unactivated XRPL address, the key check is whether destination-side funding actually created the account.

What sequence should you use for a new recipient?

For most users, the clearest route is to create and fund the destination account before bridging the token. That separates account setup from cross-chain delivery and makes failures easier to diagnose.

• Generate the destination account with a wallet or key setup you control. Confirm that you have the secret needed to authorize transactions from its address.
• Fund that address with enough XRP to meet the current base reserve. Use a source that sends XRP on the XRP Ledger, and check the destination address and network before confirming.
• After the account appears on-ledger, create the required trust line for an issued token. The account must authorize this transaction; a bridge cannot create a trust line on its behalf unless the service explicitly supports that operation.
• Bridge the token using a route that identifies the correct destination asset and address. If the bridge requires a destination tag or other routing field, follow its instructions; tags used by shared service accounts are not a substitute for controlling the destination keys.

The XRP needed to establish the account and any later reserve for ledger objects are separate from bridge fees. On mainnet, the first two trust lines have a reserve exception under current rules, but creating them still requires an account transaction and can involve a transaction fee. Check the applicable reserve and fee settings before planning the amount.

How do you verify delivery and diagnose a failure?

Verify each chain independently. First, confirm the source transaction succeeded and the bridge recognizes it. Then inspect the destination ledger for the account and the expected balance or trust line. A wallet’s token list can omit an asset it does not display, so use ledger data to distinguish a display issue from a failed delivery.

If the destination has no AccountRoot entry, the address was not activated. If the account exists but the issued token is absent, check whether the required trust line exists and whether the bridge completed its destination transaction. If the bridge reports completion while neither appears, compare the destination transaction and bridge status before submitting another transfer; repeating the source transaction can create a second payment without fixing the first one.

The practical rule is simple: treat account creation, trust-line setup, and token bridging as distinct state changes unless the bridge documents an atomic flow that handles them. For a new XRPL recipient, pre-funding the account and preparing its trust line is usually the more predictable route. A bridge’s “complete” status describes its transfer process; the destination ledger shows what the recipient can actually use.