A shared state, not just a list of payments
Each XRPL server maintains a copy of the ledger's current state. That state includes accounts, XRP balances, settings, offers, trust lines, escrows, and other protocol objects. Servers also track transactions that transformed an earlier state into the current one.
A completed version of that shared state is called a ledger version. It has a position in history, identified by a ledger index, and a cryptographic hash tied to its contents. Ledger versions build on one another to form the network's public history.
Accounts and authorization
An XRPL account has an address, an XRP balance, a sequence number, transaction history, and one or more ways to authorize transactions. The sequence number helps ensure that transactions from an account are applied in the intended order and not repeated under the same sequence.
Control comes from cryptographic keys, not from a username-and-password account held by a network administrator. A valid digital signature proves authorization. Losing secret key material can mean losing control, because the network has no privileged operator who can reverse a valid transaction.
From signed instruction to candidate transaction
A user or application constructs a transaction, signs it, and submits it to an XRPL server. The server checks the transaction against protocol rules and its view of the open ledger. If eligible, the transaction is relayed through the peer-to-peer network as a candidate for a future ledger version.
Submission is not final confirmation. Servers can initially return tentative results because the next transaction set and its ordering have not yet been agreed. The consensus process determines which candidates enter the next ledger and the canonical order in which they are applied.
Open the related live demo or evidence lab →Validation makes the result authoritative
After agreeing on a transaction set, servers independently apply the transactions according to the same rules. Validators share signed statements about the resulting ledger. When a server observes sufficient agreement from the validators it trusts, it marks that ledger version validated.
A transaction's success or failure is authoritative only when tied to a validated ledger. This is why reliable applications check the validated status and transaction metadata rather than assuming an initial submission response is final.