How XRP Ledger Consensus Works: Validators, UNLs and Voting Rounds

If two transactions conflict, which one counts? A bank answers with a central database. The XRP Ledger answers with a protocol every participant runs, so nobody has to be trusted with the database. Read this once and the fee, reserve and amendment rules stop looking arbitrary. If the ledger itself is new to you, start here.

What the protocol decides

Consensus is the task of reaching agreement within a distributed system even when some participants are faulty or malicious. On the XRP Ledger it decides which set of transactions goes into the next ledger version and how they are ordered. It is the most important property of any decentralized payment system.

Anyone can join the network, and each participant picks a subset of peers it trusts not to collude to defraud it. The protocol, as xrpl.org frames it, ranks three priorities in order: Correctness, Agreement and Forward Progress.

There is no proof of work here. The ledger runs its own protocol, an alternative that does not consume computational resources needlessly. Confirming transactions takes no wasteful or competitive use of resources, unlike most other blockchains. Entries are agreed by trusted validators, not by whoever spends the most computing power.

The double-spend problem consensus solves

The double-spend problem is the challenge of preventing someone from spending the same digital money twice. The hard part is putting transactions in order. In fact, the double-spend problem reduces to ordering transactions.

The ledger solves it with shared rules, not a referee. Every participant follows the same rules, so each can agree on the exact same series of events and outcomes at any point in time. Transactions in an agreed set run under deterministic rules, and when two conflict, whichever comes first under the sorting rules succeeds while the other fails.

One round, start to finish

A round is a series of proposals and votes that ends when a supermajority agrees on one set of transactions. It moves through three phases:

Inside Establish, five things happen:

• Initial position. Each participant starts from the set of valid transactions it has seen.
• Inclusion vote. A transaction with majority support is included; one without is deferred.
• Rising threshold. In the first round at least 50% of peers must agree, and the final threshold is 80%. The climb is deliberate: a low bar at first lets a wide set of transactions into a node’s position, while a higher bar when the node is stuck focuses on the transactions with the most support. The ladder also keeps consensus from stalling near 50%.
• Deferral. A transaction that falls below the threshold fails that round but stays a candidate for the next ledger version. Typically a transaction left out of one version is included in the next.
• Declaring consensus. Once a participant sees a supermajority agreeing on the set to process next, it declares consensus reached.

Those percentages are protocol settings, not laws of nature, and these values are subject to change. The 50% and 80% figures are the ones given for the first and final rounds. When validators disagree at first, they modify their proposals to match the validators they trust more closely and repeat until consensus is reached over several rounds.

Validation

Validation is the second stage: it verifies that the servers got the same results and declares a ledger version final. When consensus completes, each server independently computes a new ledger from the agreed set of transactions. The standard quorum is 80% of a server’s trusted validators, and a ledger needs at least 80% of peers to agree to be validated. Then it is final.

The next round does not wait. The ledger runs more efficiently by starting a new round of consensus concurrently, before validation has completed.

Choosing who to trust

Each participant picks validators: servers configured to take an active part in consensus, run by different parties who are expected to behave honestly most of the time. That list is the Unique Node List, or UNL. A UNL is a server’s list of validators it trusts not to collude, and each entry should be an independent entity: a business, a university, another organization or an individual hobbyist. Default servers use two lists, one from the XRP Ledger Foundation and one from Ripple. Anyone can publish a list, as a signed JSON document. A validator improves its odds of being listed by running with high uptime for at least a year, with high agreement with the network.

List publishers do not take part in day-to-day validation, yet they hold real power, because they choose which validators are widely trusted; the UNL documentation is blunt about it. Servers identify each other by public key on a peer-to-peer network that uses a gossip protocol, relaying digitally signed messages from others.

Overlap between lists matters for safety. It was once believed that 60% overlap between two servers’ UNLs was enough to keep them from forking apart, but later research found that 90% overlap was needed in the worst case.

How many validators can fail

The network keeps working while fewer than 20% of trusted validators are faulty, and confirming an invalid transaction would take over 80% of them colluding. In between, it stops rather than guessing.

The Negative UNL

The Negative UNL documentation covers one failure case. If more than 20% of trusted validators go offline or cannot communicate with the rest of the network, servers stop validating new ledgers because they cannot reach a quorum. The Negative UNL softens that: it is a list of trusted validators believed to be offline or malfunctioning, as declared by a consensus of the remaining validators. Validators on it are ignored when deciding whether a new ledger version has attained consensus.

Each server measures reliability as the percentage of the last 256 ledgers in which a validator’s validation vote matched the server’s view of consensus. Below 50%, a validator becomes a candidate for the list. To keep the network from fragmenting, the quorum has a hard minimum of 60% of total validators. The feature requires the NegativeUNL amendment.

The engineering spec gives a worked example: with 10 validators on a UNL, at least 8 must agree with the latest ledger for it to become validated. That is the 80% quorum applied to a small list, an illustration and not a network figure. The network will not confirm transactions that contradict its rules or history unless a supermajority above 80% agrees.

All of this is what the Byzantine Fault Tolerant label on the consensus algorithm refers to. Byzantine failures are possible and do happen, but the consequence is only minor delays.

Speed, and what a ledger holds

The ledger settles in near real time, in three to six seconds. A contested round takes longer than an uncontested one, so treat the figure as typical, not guaranteed.

Each ledger version has a ledger index and builds on the version whose index is one less, back to the genesis ledger with index 1. Unlike many blockchains, each new ledger holds the entirety of the current state, so you do not need the whole history to know what is happening now. Due to a mishap early on, ledgers 1 through 32569 were lost, which makes ledger 32570 the earliest available anywhere.

Validators also agree on a close time for each ledger. Rounding lets servers derive a common time without perfectly synchronized clocks. If peers cannot agree on close time, the effective close time is 1 second past the prior close.

What the design gives up

Safety comes first. The network favors safety and correctness over advancing the ledger. A network with possible double spends has no utility, so every honest participant values agreement above everything but correctness. If too many participants are unreachable or misbehaving, the network fails to make progress rather than diverging or confirming invalid transactions.

Perfect consensus cannot be guaranteed, because it is not practical to build an algorithm that never fails to reach it. Now and then the whole network fails to make forward progress for a few seconds. In exchange, average transaction confirmation times are low.

Validators also vote on protocol changes. An amendment passes when it keeps more than 80% support for two weeks, and the change then applies permanently to all subsequent ledger versions. Network settings go through a similar vote: the account reserve guide shows how reserve values change that way, and the transaction cost guide covers the fee side. The rest of Basics covers amendments and how XRP differs from the ledger.