Understanding XRP Ledger Transactions: A Comprehensive Guide

The XRP Ledger is a decentralized blockchain technology that enables fast and efficient transactions. This guide provides an in-depth look at the core concepts, structures, and processes involved in XRP Ledger transactions, from account creation to transaction validation.

Core Concepts of the XRP Ledger

Accounts

An account in the XRP Ledger represents an address that can hold XRP and send transactions. Each account has several key components:

• A unique address (e.g., rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn)
• An XRP balance, part of which is held in reserve
• A sequence number that starts at 1 and increments with each transaction sent from the account
• A transaction history of all transactions that have affected the account

• One or more methods of authorizing transactions, which may include:

  • A master key pair (inherent to the account)
  • A regular key pair (can be rotated)
  • A list of signer addresses for multi-signing

Account data is stored in the AccountRoot ledger object type within the ledger's data tree.

Creating an Account

There is no dedicated "create account" transaction. Accounts are automatically created when a payment sends XRP equal to or greater than the account reserve to a non-existent address. This process is known as funding an account.

Important: Funding an account doesn't grant any special privileges. Whoever controls the private key associated with the address has complete control over the account and its XRP balance.

To obtain an account on the XRP Ledger:

1. Generate a key pair from a strong random source and calculate its address
2. Have someone with an existing XRP Ledger account send XRP to your generated address

When an address receives XRP for the first time, it must pay the account reserve (currently 20 XRP), which remains locked indefinitely.

Addresses

XRP Ledger addresses use base58 encoding with a Ripple-specific alphabet. They have these characteristics:

• 25-35 characters in length
• Begin with the character 'r'
• Use alphanumeric characters excluding '0', 'O', 'I', and 'l'
• Are case-sensitive
• Include a 4-byte checksum

Special Addresses

Some addresses have special meanings or historical uses in the XRP Ledger, including "black hole" addresses where any XRP sent is permanently lost:

Account Persistence

Once created, an account permanently exists in the XRP Ledger's data tree. This is necessary to track the account's transaction sequence number and prevent replay of old transactions.

Unlike Bitcoin and other cryptocurrencies, each new ledger in the XRP Ledger contains the complete state, which grows with each new account. Institutions representing many users are encouraged to use source and destination tags to distinguish between customer payments while using fewer XRP Ledger accounts.

Transaction History

Transaction history is tracked through a chain of transaction hashes linked by ledger indexes. The AccountRoot object contains a hash of the most recent transaction that modified it, and each transaction's metadata includes the previous state, allowing reconstruction of an account's history.

A "complete" transaction history includes not just the account's direct transactions but also modifications to objects owned by the account, such as:

• RippleState objects (trust lines)
• DirectoryNode objects (owner directories)
• Offer objects (outstanding orders)
• PayChannel objects (payment channels)
• Escrow objects (time-locked payments)
• SignerList objects (multi-signing addresses)

Address Encoding

XRP Ledger addresses use base58 encoding with the Ripple dictionary. The encoding process involves:

1. Starting with a 33-byte ECDSA secp256k1 public key or 32-byte Ed25519 public key
2. Calculating the RIPEMD160 hash of the SHA-256 hash of the public key (account ID)
3. Calculating a checksum from the SHA-256 hash of the SHA-256 hash of the payload
4. Encoding the concatenated payload and checksum using base58

👉 Explore address generation tools

Cryptographic Keys

Digital signatures prove that transactions are authorized to perform specific operations. Only signed transactions can be submitted to the network and recorded in validated ledgers.

Generating Key Pairs

Use the wallet_propose method to generate key pairs. The response includes:

• Private key in multiple formats (master_key, master_seed, master_seed_hex)
• Public key in multiple formats (public_key, public_key_hex)
• Account ID derived from the public key
• Key type indicating the cryptographic algorithm used

Generated key pairs can serve as master key pairs, regular key pairs, or members of signer lists.

Master Key Pairs

The master key pair consists of a private and public key that are intrinsically linked to an account's address. The master private key is the only key that can:

• Disable the master public key
• Permanently give up the ability to freeze assets
• Send key reset transactions with 0 fee

Regular Key Pairs

Accounts can authorize a secondary key pair (regular key pair) to sign transactions while keeping the master key pair offline. If a regular private key is compromised, it can be deleted or replaced without changing the account address or reestablishing relationships with other accounts.

Regular key pairs must be explicitly assigned to an account using the SetRegularKey method. Once assigned, an account has two associated key pairs:

• The master key pair (kept offline)
• The regular key pair (used for signing transactions)

Regular key pairs can be changed or removed at any time, providing security flexibility.

Account Reserves

To submit transactions, accounts must maintain a minimum amount of XRP in the shared global ledger that cannot be sent to other addresses. This reserve requirement has two components:

• Base reserve: The minimum XRP required for each address in the ledger (currently 20 XRP)
• Owner reserve: Additional XRP required for each ledger object owned by the address (currently 5 XRP per object)

When objects are removed from the ledger, they no longer count toward the owner's reserve requirement.

Transaction Fees

To protect the XRP Ledger from spam and denial-of-service attacks, each transaction must destroy a small amount of XRP. Unlike other cryptocurrencies, XRP transaction fees are not awarded to validators but are permanently destroyed, making existing XRP more scarce and valuable.

Current Transaction Costs

The minimum transaction cost is currently 0.00001 XRP (10 drops), which increases with network load. Different transaction types have different cost structures:

Fee Escalation Mechanism

With the FeeEscalation amendment enabled, transaction costs have two thresholds:

• Local load-based cost: If a transaction's fee doesn't meet a server's threshold, the server ignores it completely
• Open ledger cost: If a transaction's fee doesn't meet this threshold, the server queues it for a subsequent ledger

This creates three categories of transactions:

1. Those rejected for insufficient fees
2. Those included in the current open ledger
3. Those queued for later ledger versions

Querying Transaction Costs

Use these methods to query current transaction costs:

• server_info method: Returns validated_ledger.base_fee_xrp multiplied by the current load_factor
• server_state method: Returns the direct representation of the server's internal load calculation
• fee method: Queries the open ledger transaction cost (if FeeEscalation amendment is enabled)

Specifying Transaction Costs

Each signed transaction must include a fee in the Fee field, which cannot be changed once signed. It's recommended to query the current transaction cost before signing and specify a slightly higher fee to account for potential network load increases.

Submitting and Validating Transactions

Transaction Lifecycle

Transactions in the XRP Ledger follow a specific timeline:

1. An account owner creates and signs a transaction
2. The owner submits the transaction to the network as a candidate
3. Through consensus and validation, the transaction is applied to a ledger
4. The validated ledger includes the transaction, with its effects reflected in the ledger state

Submission Process

To submit transactions reliably:

1. Build and sign the transaction (include a LastLedgerSequence parameter)
2. Persist transaction details (hash, LastLedgerSequence, sender address and sequence)
3. Submit the transaction

Validation Process

During normal operation, applications can check transaction status by hash or receive notifications when transactions are validated. After disruptions, applications need to reliably verify the status of transactions that may or may not have been submitted before the interruption.

The validation process involves:

• Querying transactions by hash
• Checking if results appear in validated ledgers
• Handling cases where transactions aren't found
• Determining if missing transactions failed permanently

Development Implementation

To implement transaction submission and validation, applications need to:

1. Determine the signing account's next sequence number
2. Decide on a LastLedgerSequence based on the last validated ledger
3. Build and sign the transaction (persist details before submission)
4. Submit the transaction
5. Confirm the transaction's final result

Applications can use various interfaces including the rippled API, RippleAPI, or other APIs built on top of rippled.

👉 Get advanced transaction methods

Frequently Asked Questions

What is the minimum XRP balance required for an account?

The current minimum reserve requirement is 20 XRP for the base reserve plus 5 XRP for each additional ledger object owned by the address.

How are transaction fees different in XRP Ledger compared to other blockchains?

Unlike Bitcoin and similar cryptocurrencies where fees reward miners, XRP transaction fees are permanently destroyed. This makes existing XRP more scarce and benefits all XRP holders.

Can I recover XRP sent to an incorrect address?

If XRP is sent to a "black hole" address (one without a known private key), those funds are permanently lost. Always verify addresses before sending transactions.

What happens if a transaction doesn't get included in a ledger before its LastLedgerSequence?

If a transaction isn't included in a ledger by the specified LastLedgerSequence, it permanently fails and will never be executed. You would need to submit a new transaction with a higher sequence number.

How can I improve transaction reliability during network congestion?

During high network congestion, specify a higher transaction fee to increase the likelihood of your transaction being included in the next ledger. Also, ensure you set an appropriate LastLedgerSequence value.

What's the difference between master keys and regular keys?

Master keys are intrinsically tied to an account's address and can perform all operations. Regular keys are secondary keys that can be rotated or replaced without changing the account address, providing better security flexibility for daily operations.