The XRP Ledger reaches agreement through a protocol in which a set of trusted validators propose and revise the same list of transactions until a supermajority, at least 80 percent, agrees on the exact contents of the next ledger version. There is no mining race and no staked deposit (source: Investopedia, Ripple and XRP). Agreement comes from overlapping trust between independently run servers, not from spent energy or locked capital.
This is the mechanism behind the settlement most people only see the result of: a payment that clears in a few seconds. This guide stays on the protocol itself, the how of agreement. For the wider picture of how a transaction moves through the network end to end, see the parent guide, how the XRP Ledger works.
A short warning on register: this is one of the more technical corners of the XRP world. The payoff is understanding why the network can be both fast and hard to corrupt at the same time.
What problem consensus actually solves
Consensus solves the double-spend problem: stopping the same money from being spent twice. In a system with no central operator, the hard part is agreeing on order, deciding which of two conflicting transactions came first. The XRP Ledger's job is to get every honest server to settle on one identical, final answer (source: XRP Ledger, consensus protocol).
A bank does this with a single authoritative database. A decentralized ledger cannot, because no one participant is allowed the final say. Instead the protocol defines rules that every server follows, so they independently arrive at the same series of events and the same outcome.
The XRP Ledger states its priorities in a fixed order: correctness first, then agreement, then forward progress. That ordering matters later. When the network is stressed, it will choose to stop and stay correct rather than push ahead and risk two versions of history.
Validators and the Unique Node List
A validator is a server that takes part in consensus, run by an independent party (source: XRP Ledger, run a validator). Each server picks a list of validators it trusts, its Unique Node List, or UNL. That list is chosen not for honesty but for the expectation its members will not all collude the same way.
This is the core design choice, and it is genuinely different from other blockchains. Bitcoin weights influence by hashing power; proof-of-stake systems weight it by coins locked up. The XRP Ledger weights it by trust. Your influence over the ledger comes from how many other participants have chosen to list you, not from how much money or hardware you control.
That choice defends against a specific attack. If every server simply counted proposals from anyone, an attacker could spin up thousands of validators and drown out the honest ones, a Sybil attack. Because servers only count proposals from validators on their chosen list, adding more anonymous servers buys an attacker nothing (source: XRP Ledger, consensus protections). To keep the many independent lists overlapping enough to stay consistent, the XRPL Foundation and Ripple publish signed recommended lists that most operators draw from, though each operator is free to edit its own. Who runs those validators, and how concentrated that set really is, is the subject of its own guide on XRP validators and decentralization.
How agreement forms: the proposal rounds
Agreement is iterative, not a single vote. Servers collect candidate transactions, then each validator broadcasts a proposal, its set of transactions for the next ledger. Because messages take time to spread, proposals start out different. Over several quick rounds, validators revise their proposals to match what their trusted validators are proposing (source: XRP Ledger, consensus structure).
The bar rises as the rounds go. Early on, a transaction only needs roughly half of trusted validators backing it to stay in the running. By the final round, the threshold climbs to 80 percent agreement before the set is locked in. Transactions that do not make the cut are not rejected outright; they simply drop back to the candidate pool and are usually picked up in the next ledger a few seconds later.
This all happens on a cadence of a few seconds. The reason the network can move that fast is exactly that there is no puzzle to solve and no block reward to compete for. Validators are not racing each other; they are converging on a shared answer.
Validation: checking everyone got the same result
Agreeing on which transactions to apply is only half the process. Once the set is locked, every server independently computes the resulting ledger on its own, following identical rules: start from the last validated ledger, put the transactions in a fixed canonical order, apply each one, then calculate a cryptographic hash of the result.
Canonical order is doing quiet but important work here. Servers receive transactions in different orders, so the protocol forces a single deterministic ordering that is hard to manipulate. That way every honest server, applying the same transactions the same way, must arrive at the same final ledger, down to the same hash.
Each validator then broadcasts a signed message containing that hash. These are the validations. When a server sees that at least 80 percent of its trusted validators signed the same hash, it treats that ledger version as validated and final; its contents can never change after that. A server that computed a different result knows it is in the minority, discards its own version, and fetches the correct one. Only one validated ledger can ever exist for each ledger index, which is why the history cannot quietly branch into two.
The fault tolerance math, and why the network sometimes halts
The safety comes down to two numbers. As long as fewer than 20 percent of a server's trusted validators are faulty or dishonest, consensus continues normally. To force an invalid transaction through, an attacker would need more than 80 percent of trusted validators to collude in the same fraud, which the UNL design is built to make impractical.
The interesting case is the middle. If more than 20 percent but fewer than 80 percent of trusted validators are unreachable or misbehaving, the network does not guess and it does not split. It stops making progress until enough validators come back into agreement. This property is what makes the protocol byzantine fault tolerant: it keeps working through a wide range of failures and, past its limit, fails safe.
To a user that middle case looks like a pause, and it is a deliberate one. This is the correctness-first priority in action. A halted ledger that later resumes with one true history is a far smaller problem than two conflicting histories that both claim to be real, which is the failure a payment network can never afford. In practice such stalls have been rare and short, but the design would rather freeze than fork.
Why it uses neither mining nor staking
Mining secures a chain by making history expensive to rewrite: an attacker must out-compute the honest network. Proof of stake ties security to capital at risk. The XRP Ledger takes a third path, basing security on a web of overlapping trusted lists, so it needs neither a hashing race nor a bonded deposit.
The practical differences follow directly. There is no block reward, so validators are not paid in new XRP for taking part; they run the software because a reliable network is worth more to them than a subsidy would be. In practice they are operated by exchanges, payment businesses, universities, and community members with a direct stake in the ledger staying healthy. And because no one is burning electricity to win a block, settlement is quick and the energy cost per transaction is very low (source: Kraken, what is XRP). If you want the general theory behind the alternatives it replaces, that lives in the comparison of proof of work versus proof of stake.
The trade-off is honest to name. Trust-based validation depends on the validator set staying diverse and genuinely independent; concentrate it too far and the security argument weakens. That is why decentralization of the validator set, rather than raw speed, is the metric worth watching over time.
Frequently asked questions
Do validators earn XRP for running consensus?
No. The XRP Ledger has no block reward, so validators are not paid in new XRP for taking part. They are typically run by exchanges, financial firms, universities, and community members who want a dependable network. The transaction fees that senders pay are destroyed, not handed to validators.
Can the XRP Ledger fork into two competing chains?
It is designed not to. Only one ledger can be validated for each ledger index, and if trusted validators cannot reach the 80 percent supermajority, the network halts instead of splitting. That correctness-first choice trades a possible short pause for a guarantee that two conflicting histories do not both survive.
Who decides which validators everyone trusts?
Each server operator chooses its own Unique Node List, so no central party assigns trust. In practice most operators start from a signed recommended list the XRPL Foundation and Ripple publish, then can adjust it. The network stays consistent because these independent lists overlap heavily, not because anyone controls them.
Researched and written for the BloFin Academy. This article is educational and is not financial, investment, or legal advice. Always do your own research.