Transactions flow through governance approval, cryptographic signing, and blockchain broadcast, with full status tracking at every stage.
- Every transaction passes through policy checks before signing (governance cannot be bypassed).
- Fee strategies let you balance cost vs. confirmation speed per transaction.
- Both hot vaults (online signing) and cold vaults (air-gapped) are supported.
- Status tracking covers internal processing through blockchain finality.
Understanding the transaction lifecycle is essential for operations and integration. Every transaction is gated by your policies—this is how you enforce spending limits, multi-party approval, and compliance controls. Fee strategies directly impact cost and user experience (under-priced transactions may be delayed; over-priced wastes money). Status tracking enables real-time monitoring and reconciliation.
For architects and operators: Monitor transaction status distribution to identify bottlenecks (many in "Pending" = approval backlog; many in "Preparing" = fee issues). Configure appropriate fee strategies per use case — high-priority for customer withdrawals, lower priority for internal treasury movements.
A blockchain transaction is a digitally signed instruction that requests a change on a distributed ledger. Unlike traditional financial systems where a central authority processes transfers, blockchain transactions are:
- Cryptographically signed: The sender proves ownership of their assets by signing the transaction with their private key (see Authentication for details on how signing works)
- Broadcast to a network: The transaction is sent to multiple nodes (computers) that validate it
- Recorded permanently: Once confirmed, the transaction becomes part of an immutable record
The following diagram shows a simplified view of how a blockchain transaction works:
- Submit signed intent: The user or service caller submits a transaction request.
- Queue workflow: Ripple Custody accepts the request for asynchronous processing.
- Policy evaluation and attestation: The notary verifies signatures, evaluates policy, and signs the trusted-state attestation.
- Attested operation: The vault receives the notary-attested operation.
- Signed transaction: The vault verifies the attestation, builds the ledger-specific transaction, and signs it through its KMS backend.
- Broadcast and monitor: Ledger Accounting broadcasts the transaction and tracks ledger status through blockchain indexing services.
In Ripple Custody, an accounting transaction is any operation that affects the balance or the system's state (such as a configuration change). This includes blockchain transactions as well as internal tracking of incoming funds.
The types of accounting transactions you can perform depend on the blockchain you're using:
| Transaction type | Description | Example use cases |
|---|---|---|
| Native currency transfer | Send the blockchain's base currency (e.g., ETH, BTC, XRP) to another address | Paying vendors, treasury management, customer withdrawals |
| Token transfer | Send tokens issued on a blockchain (e.g., ERC-20, SPL tokens) to another address | Stablecoin payments, loyalty token distribution |
| Smart contract call | Execute code stored on a blockchain to perform complex operations | DeFi interactions, NFT minting, custom business logic |
| Staking operation | Lock assets to participate in network consensus and earn rewards | Delegate tokens to validators, claim staking rewards |
Not all blockchains support all transaction types. For details on what each blockchain supports, see Supported ledgers.
For guides on performing these operations, see Send assets (UI) or Send assets (API).
When you initiate a transaction in Ripple Custody, it passes through several stages before reaching the blockchain:
| Phase | What happens | Key components |
|---|---|---|
| 1. Initiation | User submits a transaction request (transfer order or transaction order) | API Gateway, Web UI |
| 2. Governance | The notary evaluates policy and verifies whether the transaction requires additional approvals or exceeds spending limits. | Notary, policies |
| 3. Signing | Once approved and attested, the vault verifies the notary attestation and signs the blockchain transaction through its KMS backend. | Notary, vault, KMS |
| 4. Broadcast | The signed transaction is sent to the blockchain network. | Ledger Accounting, blockchain nodes |
| 5. Confirmation | The blockchain includes the transaction in a block and the system updates balances and status. | Blockchain indexing services, Ledger Accounting, PostgreSQL |
Every transaction goes through governance approval and notary attestation before signing. The vault independently verifies the notary attestation before it signs the blockchain transaction, ensuring no transaction can bypass policy controls.
For the complete technical flow with detailed sequence diagrams, API calls, and UI screenshots, see Send assets (UI) or Send assets (API).
This overview introduces the transaction lifecycle. For detailed information, see the following pages:
| Page | Description |
|---|---|
| Transaction workflow | Start with the major transaction actions and learn when to use transfer orders or transaction orders. |
| Transaction status | Understand what happens after initiation, including status progression, vault signing flows, fees, and finality. |
| Transaction reference | Look up fee strategies by ledger, finality settings, status definitions, troubleshooting notes, and glossary terms. |
| Sending assets | Find the UI and API procedures for outbound transfers. |
| Receiving assets | Find the UI and API procedures for incoming transfers and quarantine release. |
| Viewing assets | View the transaction and transfer records created when assets are sent or received. |
| Cancel or replace a transaction | Cancel a transaction before resources are fully allocated, or replace supported Bitcoin and Ethereum transactions. |
| Smart contracts + DApps | Find the UI and API procedures for smart contract operations and WalletConnect DApps. |