Blockchains and tokens

Ripple Custody (Wallet) supports multiple blockchain networks. This page describes the features available for each supported chain.

The following table shows feature availability for each blockchain.

The following table shows transaction and signing features for each blockchain.

The following table shows operational features for each blockchain.

Ripple Custody (Wallet) processes an incoming transaction as confirmed and reflects it in your wallet balance once it meets the chain-specific finality requirement below.

For block-based thresholds, the value is the number of additional blocks Ripple Custody (Wallet) waits after the block containing the transaction. Under the usual convention where the containing block is confirmation 1, a threshold of N additional blocks means the transaction has N + 1 confirmations when Ripple Custody (Wallet) processes it.

Some chains expose a finality mechanism instead of requiring Ripple Custody (Wallet) to apply an additional block threshold:

• BNB Smart Chain, Polygon, and Avalanche C-Chain — Ripple Custody (Wallet) uses the provider's native finalized block. For Avalanche C-Chain, this corresponds to the chain's consensus-accepted state.
• Solana — Ripple Custody (Wallet) uses the finalized commitment level.
• XRP Ledger — Ripple Custody (Wallet) processes transactions from validated ledgers.
• 1Money — Ripple Custody (Wallet) processes transactions from the latest checkpoint.

For BNB Smart Chain, Polygon, and Avalanche C-Chain, if the provider can't return a finalized block or its finalized head stops advancing, confirmation waits. Ripple Custody (Wallet) doesn't fall back to the latest block. Confirmation time can vary with network and provider conditions.

Applies to: Ethereum, Polygon, Arbitrum, Avalanche, Base, BNB Smart Chain, Tron

Ripple Custody (Wallet) detects a native-asset deposit, such as ETH on Ethereum or TRX on Tron, only when the deposit is the value of a transaction sent directly to your wallet address. A smart contract can also send a native asset to your wallet while it runs. That transfer is part of the contract's transaction, not a transaction of its own, and Ripple Custody (Wallet) doesn't record it:

• The deposit doesn't appear in the wallet's transaction history.
• The wallet's balance in Ripple Custody (Wallet) doesn't include it, so it's lower than the balance a block explorer shows for the same address.

Some exchanges, smart contract wallets, and decentralized applications send native assets this way. Before you share a deposit address, ask the sender to send native assets as a direct transfer to the address.

If you've already received a deposit this way, refresh the wallet's balances. A refresh reads the native-asset balance from the blockchain, so the wallet's balance then includes the deposit. A refresh doesn't add the deposit to the wallet's transaction history.

Asset sweeping doesn't move these deposits, even after you refresh the wallet's balances. A native sweep moves only deposits that Ripple Custody (Wallet) recorded. To move the funds, send a withdrawal from the wallet.

This limitation applies only to native assets. Ripple Custody (Wallet) detects ERC-20, TRC-20, and ERC-721 tokens that a smart contract sends to your wallet, as long as the token contract emits the standard Transfer event.

Ripple Custody (Wallet) doesn't detect token balance changes that don't emit a standard Transfer event. Examples include tokens with a non-standard transfer event, zero-value transfers, and rebasing tokens whose balances change without a transfer.

This section defines each feature shown in the tables above.

Ripple Custody (Wallet) classifies tokens using the following standard types. Use these types in the API when you specify token operations.

The following table summarizes which token standards are available on each blockchain.

Applies to: Ethereum, Polygon, Arbitrum, Avalanche, Base, BNB Smart Chain

EVM-compatible chains support the following token standards:

• NATIVE — The chain's native gas token: ETH on Ethereum, Arbitrum, and Base; POL on Polygon; AVAX on Avalanche; and BNB on BNB Smart Chain.
• ERC-20 — Fungible tokens following the ERC-20 standard. BNB Smart Chain uses the BEP-20 standard, which is functionally identical and mapped to ERC20 in the API.
• ERC-721 — Non-fungible tokens (NFTs). Supported operations include mint, burn, and transfer.

Solana supports the following token standards:

• NATIVE — SOL, the chain's native asset.
• SPL — Tokens issued through either the SPL Token program or the Token-2022 (Token Extensions) program. The connector supports both token programs under the single SPL standard type.

Supported token operations: transfer, mint, burn, freeze, thaw, close account, and set authority.

Tron supports the following token standards:

• NATIVE — TRX, the chain's native asset.
• TRC-20 — Fungible tokens following the TRC-20 standard. TRC-20 uses the same contract interface as ERC-20, and Ripple Custody (Wallet) maps it to ERC20 in the API.

Bitcoin supports NATIVE only (BTC). Transactions use the UTXO model.

Ripple Custody (Wallet) supports native BTC sweeping. Ripple Custody (Wallet) doesn't support Bitcoin token standards such as BRC-20, Ordinals, and Runes for sweeping or other token operations.

Ripple Custody (Wallet) supports these script types: P2PKH, P2WPKH, P2SH, P2WSH, P2TR, and nested SegWit.

XRP Ledger supports the following token standards:

• NATIVE — XRP, the ledger's native asset.
• ISSUED_CURRENCY — Trustline-based tokens issued on the XRP Ledger. These tokens require a trust line between the holder and the issuer.

Additional supported operations: clawback and AMM (Automated Market Maker) transactions.

1Money supports the following token standards:

• NATIVE — 1MONEY, the chain's native asset.
• CUSTOM — Proprietary tokens issued on the 1Money network.

Supported token lifecycle operations: create, mint, burn, freeze, pause, whitelist, blacklist, and authority management.