How XRP Ledger consensus works (the UNL and the 80% rule)
The XRP Ledger settles a transaction in three to five seconds without a single miner or staker, and that surprises people who only know Bitcoin and Ethereum. It manages it with a trust-based design built around two ideas: the Unique Node List and an 80% supermajority. Understanding those two things tells you how the ledger works and equips you to judge the decentralization debate that has followed XRP for a decade — which is the part most articles botch.
Validators who work for free
First, a detail that shapes everything else: XRP Ledger validators receive no reward. There’s no block subsidy, no staking yield, nothing. Validating is a cost, not a business. That sounds like a weakness, but it’s deliberate — it filters out mercenaries and attracts what the community calls “natural stakeholders”: exchanges, financial institutions, universities, and businesses that simply want the network they depend on to keep running honestly. Their incentive is the network’s health, not a payout.
The Unique Node List
Here’s the core mechanism. Every server on the network is configured with a Unique Node List (UNL) — the specific set of validators it trusts not to collude against it. During consensus, a server only listens to validation votes from validators on its own UNL and ignores everyone else.
Nobody is forced onto your list and nobody can force their way on. Anyone can run a validator, and each operator independently decides whose votes to count. That’s the sense in which the network is permissionless: not “anyone’s vote automatically counts,” but “anyone can run a validator, and the community decides who’s worth trusting.”
The 80% rule
A new ledger closes every few seconds. During each round, validators propose a candidate set of transactions, and the rule that finalizes it is simple: when at least 80% of the validators on a server’s UNL agree on the same candidate ledger, that server accepts it as final. Pushing the threshold that high is what gives the ledger its strong safety — to force a bad ledger through, you’d need to corrupt the overwhelming majority of trusted validators simultaneously.
Staying in sync: overlap and the Negative UNL
If everyone picks their own UNL, why doesn’t the network splinter? Because the lists overlap heavily. As long as your UNL shares more than about 90% of its members with the people you transact with, you’re safe from forking — you’ll always agree on the same history. Low overlap is what risks a split, which is why most operators converge on a common, well-vetted set.
The protocol also handles the messy reality that validators sometimes go offline. A feature called the Negative UNL lets the network temporarily discount validators that are currently unreachable, recalculating the agreement threshold so a few outages don’t stall consensus. It’s an elegant patch for the liveness problem a high supermajority would otherwise create.
The recommended lists — convenience vs. control
Choosing 35 trustworthy validators yourself is hard, so in practice most operators follow a default UNL (dUNL) — a recommended list published by a trusted party. Today there are two main publishers: the XRP Ledger Foundation and Ripple. This is the crux of the centralization argument, and it’s a fair one to raise: convenience drives convergence onto these curated lists, which concentrates a degree of soft influence in whoever publishes them.
It cuts both ways, though. The lists are recommendations, not mandates — any operator can ignore them, edit them, or follow a different publisher entirely, and the network keeps running. When the Foundation migrated its list in late 2025 and early 2026, operators had to update their configs by hand or risk disconnection — a reminder that this model carries operational fragility that proof-of-work doesn’t, but also that no single party can silently force a change.
So is XRP actually decentralized?
The honest answer is “more than critics say, less than maximalists claim — and far more than it used to be.” The numbers, from the ledger’s own documentation: there are 150+ validators, with about 35 on the default list, and Ripple now runs only one or two of them. That’s a deliberate result — Ripple pursued a multi-year policy of removing one of its own validators for every two independent, high-quality validators added, and by 2026 it no longer operates anything close to a majority.
Two clarifications that defuse most of the bad-faith arguments on both sides. First, as Yale’s Gary Gorton put it bluntly, Ripple and the XRPL are not the same entity — Ripple’s large XRP holdings give it no power to rewrite the ledger or reverse a transaction; those powers sit only with the independent validators. Second, this is genuinely a different model from proof-of-work decentralization, not a lesser copy of it: trust here is explicit and identity-based rather than anonymous and economic. Whether you find that reassuring or uncomfortable depends on what you want a payments network to be — and for the regulated institutions XRPL courts, identifiable validators are a feature, not a flaw.
Why this fits the XRP Ledger
It all serves the mission. A network built to move money for banks should settle in seconds, use almost no energy (the XRPL reportedly draws about as much power as running an email server), never fork, and be validated by identifiable parties with a real stake in its integrity. The UNL-and-80% design delivers exactly that — and the trade-offs it makes are the ones a payments rail should make.
Keep reading
I publish ongoing analysis on Stellar, XRP and Cosmos — subscribe here.
Informational only, not financial advice. Validator counts and list composition change; check a live explorer for the current picture.
Sources: XRP Ledger documentation (xrpl.org FAQ, UNL and Negative UNL docs, default UNL migration notices), XRP Ledger Foundation, and independent analyses of XRPL decentralization.
Last updated 2026-06