Reference tables for fee strategies, transaction finality, and ledger-specific configurations.
- Fee strategy options: Priority, Specified rate, EIP-1559, Beneficiary pays.
- Maximum fee acts as a cost safeguard. Transactions wait if fees exceed threshold.
- Finality varies by blockchain. Some confirm in seconds, others require multiple blocks.
- Ledger-specific details for Bitcoin-type, EVM-compatible, and other supported chains.
This reference is essential for configuring transactions correctly per blockchain. Fee strategies directly impact transaction speed and cost. Finality settings affect when you can consider a transaction "complete" for operational and accounting purposes. Incorrect settings can result in stuck transactions, unexpected costs, or premature confirmations.
For architects and operators: Bookmark this page for operations. Set appropriate maximum fees per use case to prevent cost surprises during network congestion. Understand finality requirements for each chain—some require waiting for multiple confirmations before considering funds received.
Before using this reference, you should understand:
- Transactions and transfers - Transaction lifecycle, initiation methods, and processing flow
The following values together define your approach to transaction fees:
| Setting | Description |
|---|---|
| Fee strategy | Indicates how you want fees to be applied. For example, whether you want Ripple Custody to apply a specific fee or calculate a fee based on priority. |
| Maximum fee | Sets the threshold for fees above which the transaction cannot be broadcast. Acts as a safeguard to ensure you know the maximum cost in advance. |
| Type | Description |
|---|---|
| No strategy | Ripple Custody calculates the fee using the ledger default. |
| Priority | Ripple Custody calculates and adjusts the fee based on the priority you define (Low, Medium, High). Helps mitigate volatile fee rates. Required for transfer orders. |
| Specified rate | You specify the exact fee rate, adjusted for ledger minimums. EIP 1559 variant available for Ethereum-compatible networks. |
| Specified additional fee | Ripple Custody adds your specified amount on top of the ledger base fee. |
| Beneficiary pays | The recipient pays the transaction fees. |
If the current network fee exceeds your maximum fee, Ripple Custody keeps the transaction in Preparing status until network conditions allow broadcasting within your threshold.
Ledger fees change regularly. The fee Ripple Custody calculates is an indication and may not reflect the final fee incurred on the blockchain.
The following table provides an overview of the fee strategy types available for each ledger, and the adjustments Ripple Custody makes to the fee calculation.
The only fee strategy available when sending assets using a transfer order is the Priority strategy.
| Network | Fee Strategies | Details |
|---|---|---|
| Bitcoin | Priority, Specified rate, Beneficiary pays | Fees calculated in Satoshi per vByte. For dust transactions, the dust amount is added to the transaction fee. |
| Bitcoin Cash | Priority, Specified rate, Beneficiary pays | Same as Bitcoin |
| Litecoin | Priority, Specified rate, Beneficiary pays | Same as Bitcoin |
| Dogecoin | Priority, Specified rate, Beneficiary pays | Same as Bitcoin |
| Dash | Priority, Specified rate, Beneficiary pays | Same as Bitcoin |
| Network | Fee Strategies | Details |
|---|---|---|
| Ethereum | Priority, Specified rate, Specified rate EIP 1559 | EIP 1559 rates preferred. Includes base fee + priority fee (tip). |
| Polygon | Priority, Specified rate, Specified rate EIP 1559 | Same as Ethereum |
| Binance Smart Chain | Priority, Specified rate | Legacy gas price model (no EIP 1559) |
| Avalanche C-Chain | Priority, Specified rate, Specified rate EIP 1559 | Same as Ethereum |
| Network | Fee Strategies | Details |
|---|---|---|
| XRP Ledger | Priority, Specified additional fee | Base fee from network with priority multiplier. Minimum balance: 10 XRP + 2 XRP per object. |
| Hedera | No strategy | Fee is retrieved directly from the chain and depends on operation type and USD/HBAR exchange rate. Customers cannot prioritize Hedera transactions. Minimum balance: 2 HBAR per account for renewal. |
| Stellar | Priority | Minimal fee: 0.00001 XLM (100 Stroops). |
| Algorand | No strategy | Max of minimal fee (1000 microAlgos) or fee per byte × transaction size. Minimum balance: 100,000 microAlgos. |
| Cardano | No strategy, Beneficiary pays | Fees set by ledger protocol. |
| Polkadot | No strategy | Fees set by ledger protocol. |
| Tezos | Priority | Fees set by ledger with priority adjustments. |
| Solana | No strategy | Fee is retrieved directly from the chain. Customers cannot prioritize Solana transactions. |
For a full list of supported ledgers, see Supported ledgers.
Transaction finality is the unchangeable confirmation of a transaction on a blockchain. Ripple Custody implements probabilistic finality, treating transactions as confirmed after a sufficient number of blocks.
To update the default finality values for your deployment, contact your Ripple liaison.
During the BIP-110 signaling period and the anticipated eCash fork, we recommend that you temporarily increase the required confirmation counts for all incoming Bitcoin transactions. See Bitcoin network events: BIP-110 and eCash fork.
| Network | Confirmation Blocks | Blocks for Expiry | Time to Expiry |
|---|---|---|---|
| bitcoin-mainnet | 3 | 432 | 3 days |
| bitcoin-testnet | 3 | 432 | 3 days |
| bitcoin-cash-mainnet | 12 | 432 | 3 days |
| bitcoin-cash-testnet | 3 | 432 | 3 days |
| litecoin-mainnet | 12 | 432 | 3 days |
| litecoin-testnet | 3 | 432 | 3 days |
| dogecoin-mainnet | 60 | 4,032 | 3 days |
| dogecoin-testnet | 60 | 432 | 3 days |
| dash-mainnet | 2 | 1,728 | 3 days |
| dash-testnet | 2 | 432 | 3 days |
| Network | Confirmation Blocks | Blocks for Expiry | Time to Expiry |
|---|---|---|---|
| ethereum-mainnet | 96 | 17,280 | 3 days |
| ethereum-testnet-holesky | 96 | 17,280 | 3 days |
| ethereum-testnet-sepolia | 96 | 17,280 | 3 days |
| polygon-mainnet | 200 | 112,680 | 3 days |
| polygon-testnet-amoy | 200 | 112,680 | 3 days |
| bsc-mainnet | 96 | 86,400 | 3 days |
| bsc-testnet | 96 | 86,400 | 3 days |
| avalanche-c-chain-mainnet | 1 | 86,400 | 3 days |
| avalanche-c-chain-testnet-fuji | 1 | 86,400 | 3 days |
| Network | Confirmation Blocks | Blocks for Expiry | Time to Expiry |
|---|---|---|---|
| xrpl-mainnet | 1 | 21,600 | 1 day |
| xrpl-testnet | 1 | 21,600 | 1 day |
| tezos-mainnet | 30 | 8,640 | 3 days |
| tezos-testnet | 30 | 8,640 | 3 days |
| substrate-polkadot | 1 | 43,200 | 3 days |
| substrate-westend | 1 | 43,200 | 3 days |
| cardano-mainnet | 30 | 12,960 | 3 days |
| cardano-testnet | 30 | 12,960 | 3 days |
| solana-mainnet | 31 | 648,000 | 3 days |
| solana-devnet | 31 | 648,000 | 3 days |
| stellar-mainnet | 1 | 51,840 | 3 days |
| stellar-testnet | 1 | 51,840 | 3 days |
| algorand-mainnet | 1 | 57,600 | 3 days |
| algorand-testnet | 1 | 57,600 | 3 days |
| hedera-mainnet | 1 | 129,600 | 3 days |
| hedera-testnet | 1 | 129,600 | 3 days |
Networks with different consensus mechanisms require different confirmation thresholds:
- Fast finality (1 block): XRP Ledger, Stellar, Algorand, Hedera, Avalanche, Polkadot
- Medium finality (2-31 blocks): Bitcoin, Dash, Cardano, Tezos, Solana
- High confirmation (96+ blocks): Ethereum, BSC, Polygon
For a complete description of transaction statuses, see Transaction processing.
| Status | Stage | Description |
|---|---|---|
Pending | Ripple Custody | Approved by policy evaluation, awaiting preparation |
Preparing | Ripple Custody | Fetching ledger data (nonce, UTXO, fees) |
Reserved | Ripple Custody | Resources allocated, affects Reserved balance |
Prepared | Ripple Custody | Notary attestation obtained, ready for vault verification |
Broadcasting | Ripple Custody | Transaction submitted to blockchain |
Completed | Ripple Custody | Successfully broadcast, awaiting confirmation |
Failed | Ripple Custody | Transaction failed (see failure reasons) |
Detected | Ledger | Visible in mempool or first block |
Confirmed | Ledger | Required confirmation blocks reached |
Replaced | Ledger | Transaction replaced on-chain |
Expired | Ledger | Confirmation not reached in time |
This section covers common transaction issues and their resolutions.
Symptoms: Transaction remains in Preparing for an extended period.
Possible causes:
- Network fees exceed your maximum fee setting
- Blockchain node connectivity issues
- Missing UTXO (Bitcoin-type ledgers)
Resolution:
- Check current network fee levels against your maximum fee
- If fees are high, wait for network conditions to improve or increase maximum fee
- Verify blockchain node connectivity in the system status
Symptoms: Transaction status shows Failed.
Common causes and resolutions:
| Cause | Resolution |
|---|---|
| Insufficient balance | Ensure account has enough funds including fees |
| Invalid recipient address | Verify the destination address format |
| Expired transaction | Resubmit the transaction |
| Smart contract revert | Check contract requirements (gas limit, parameters) |
| notary rejection | Contact support; may indicate version mismatch |
Symptoms: Transaction shows Confirmed but expected action didn't occur on-chain.
Explanation: A Confirmed status means the transaction was included in a block, not that the operation succeeded. The on-chain operation may have failed due to:
- Malformed smart contract data
- Insufficient gas for execution
- Contract-level authorization failure
- Token not associated with recipient (Hedera)
Resolution: Check the blockchain explorer for the transaction receipt and error details.
Symptoms: Transaction shows Replaced status.
Explanation: A replacement transaction was broadcast with the same nonce (EVM) or spending the same UTXO (Bitcoin-type). This typically happens when:
- You manually requested a replacement
- A stuck transaction was replaced with a higher fee
The original transaction will not confirm; only the replacement will.
For additional support, contact your Ripple liaison or check the Ripple Custody status page.
When a transaction is prepared in the Ripple Custody UI, the system automatically executes a dry-run of the operation. If an anomaly impacts the indexers or (blockchain) nodes, you may encounter the following errors:
| Error | Possible root cause | Consequence |
|---|---|---|
Payload has validation issues preventing the execution of the dry-run | The indexer or ledger accounting service isn't available. | You can't broadcast a transaction because the system can neither prepare nor detect transactions. The accounts' balance may differ from the on-chain balance. |
Tracker identification failed | The indexer is unable to establish a connection to the node. | You can't broadcast a transaction because of the missing connection between the indexer and the node; no accounting operation will be performed. |
Tracker not in sync | The indexer or node was unavailable for a period of time. | You can still broadcast a transaction, but expect a delay in detecting both inbound and outbound transactions, which impacts the accounts' balance. |
If you encounter an error where the indexer and node are out of sync, avoid broadcasting transactions. If you must make an urgent transaction, manually verify the transaction details first.
| Term | Definition |
|---|---|
| drops | The smallest unit of XRP. 1 XRP = 1,000,000 drops. |
| EIP 1559 | Ethereum Improvement Proposal 1559, which introduced a base fee + priority fee (tip) model for transaction fees, replacing the legacy gas price auction. |
| Gas | A unit measuring computational effort on EVM-compatible blockchains. Transaction fees = gas used × gas price. |
| lovelace | The smallest unit of ADA (Cardano). 1 ADA = 1,000,000 lovelace. |
| microAlgos | The smallest unit of ALGO (Algorand). 1 ALGO = 1,000,000 microAlgos. |
| micro tez | The smallest unit of XTZ (Tezos). 1 XTZ = 1,000,000 micro tez. Also called mutez. |
| Nonce | A transaction counter, starting at 0, that represents the number of operations sent to an EVM blockchain from an account. |
| Plancks | The smallest unit of DOT (Polkadot). 1 DOT = 10,000,000,000 Plancks. |
| Satoshi | The smallest unit of BTC (Bitcoin). 1 BTC = 100,000,000 Satoshis. |
| Stroops | The smallest unit of XLM (Stellar). 1 XLM = 10,000,000 Stroops. |
| tinybar | The smallest unit of HBAR (Hedera). 1 HBAR = 100,000,000 tinybars. |
| UTXO | Unspent transaction output. A digital currency resource used on Bitcoin-type ledgers representing cryptocurrency available to be spent. |
| vByte | Virtual byte, a unit of measurement for Bitcoin transaction size that accounts for SegWit discount. Used to calculate fees. |
| Wei | The smallest unit of ETH (Ethereum). 1 ETH = 1,000,000,000,000,000,000 Wei (10¹⁸). |