A Transaction is the sole mechanism for modifying the XRP Ledger. These transactions become final only when they are signed, submitted, and accepted into a validated ledger version through the consensus process. The ledger also includes _pseudo-transactions_, which are unsigned but must still gain consensus approval. Even failed transactions appear in ledgers because they modify XRP balances to cover the transaction cost, which serves as an anti-spam measure.
Transactions extend beyond simple payments. They support various Payment Types and enable functions like rotating cryptographic keys, adjusting account settings, and participating in the XRP Ledger's decentralized exchange. The rippled API reference provides a comprehensive list of transaction types.
Identifying Transactions
Each signed transaction features a unique "hash" identifier. Servers provide this hash upon submission, and you can retrieve it later via the account\_tx command.
Transaction hashes double as "proof of payment" since anyone can verify a transaction's final status by its hash.
Note: Early SetFee pseudo-transactions created an exception to hash uniqueness. Two instances shared identical fields and the same hash (1C15FEA3E1D50F96B6598607FC773FF1F6E0125F30160144BE0C5CBC52F5151B), appearing in ledgers 3715073 and 3721729 respectively. Modern SetFee transactions include a LedgerSequence field to ensure uniqueness.
Claimed Cost Justification
Charging a transaction cost for failed transactions serves critical purposes:
- Preserves sequence numbering for subsequent transactions
- Deters network abuse by making failed transactions costly
- Maintains minimal real-world expense for users
👉 Explore transaction security best practices
Transaction Authorization
The XRP Ledger validates transactions through digital signatures, which prove authorization. Only signed transactions enter the network and reach validated ledgers. Authorization methods include:
- Master private key signatures (enabled/disabled via AccountSet)
- Regular key pair signatures (managed via SetRegularKey)
- Multi-signatures (configured via SignerListSet)
Restrictions:
- Only master keys can disable master public keys
- Only master keys can permanently relinquish freeze capabilities
- Addresses must retain at least one signing method
Transaction Process
Executing transactions involves:
- Creating an unsigned JSON transaction
- Authorizing with valid signature(s)
- Submitting to an XRP Ledger server
- Gaining consensus approval
- Applying to the ledger in canonical order
- Achieving immutable validation
Example Unsigned Payment:
{
"TransactionType" : "Payment",
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
"Amount" : {
"currency" : "USD",
"value" : "1",
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
},
"Fee": "12",
"Flags": 2147483648,
"Sequence": 2
}Transaction Verification
Validated transactions include metadata showing outcomes and state changes. Check status via API commands like tx.
Caution: Results aren't final until appearing in a validated ledger (Finality of Results).
👉 Learn advanced transaction monitoring techniques
FAQ
Q: Why do failed transactions incur costs?
A: They prevent sequence renumbering, deter spam, and maintain network integrity despite minimal user expense.
Q: How many authorization methods can an address have?
A: Multiple, but it must always retain at least one signing capability.
Q: What makes transaction results immutable?
A: Validation through consensus creates cryptographic certainty in the ledger's state.
Q: Can transaction hashes ever duplicate?
A: Extremely rarely—only two early pseudo-transactions share identical hashes in XRP Ledger history.
Q: Where can I find comprehensive transaction documentation?
A: The XRP Ledger Dev Portal offers complete technical references.