The Ripple Protocol Consensus Algorithm: Agreement by Trusted Lists

A historical draft, read with care

The paper, “The Ripple Protocol Consensus Algorithm” by David Schwartz, Noah Youngs and Arthur Britto (Ripple Labs, 2014), opens with a notice added later. It says the draft does not reflect the current state of the ledger consensus protocol or its analysis, that it is hosted only for historical interest, and that it should not be used as a reference. It points readers to an updated analysis posted to arXiv in February 2018.

That matters for how we use it. On this page we explain the original ideas because they are a clear example of a design family: consensus built on who you choose to listen to rather than on spending energy. We do not claim that every number below describes how the live network behaves today.

The three problems the authors set out to solve

The paper groups the challenges of any distributed payment system into three. Correctness means telling a genuine transaction from a fraudulent one when you may not even know who the participants are. Agreement means keeping one shared truth, so that a user cannot submit two payments that are each fine alone but together spend the same money twice (the double-spend problem). Utility is the practical question of whether the system is usable, which the authors mostly reduce to latency: a system that is correct but takes a year to settle a payment is not a payment system.

They frame this as a version of the classic Byzantine Generals problem, where some participants may be traitors or messages may be lost. They also recall a well-known result, often called FLP after its authors, which shows that with no bound on message delays an agreement protocol can always be stopped from finishing by even a single faulty process. That is why the design uses time-based rules to keep the process moving.

The building blocks

The paper defines a small vocabulary. A server runs the consensus software; a client only sends and receives funds. The ledger records how much each account holds and is the network’s ground truth. Each server keeps an open ledger of work in progress, and the most recently ratified version is the last-closed ledger. A transaction is not final until it has passed through consensus and the open ledger becomes the last-closed one.

The central idea is the Unique Node List (UNL): the set of other servers a particular server consults when deciding. Only votes and proposals from the UNL count. The authors stress that this kind of trust does not require believing in any single member. What is required is that the group as a whole is unlikely to collude.

How one round of consensus works

Every few seconds the servers run a round. Each server gathers the valid transactions it has seen that are not yet applied and publishes them as its candidate set. It then combines the candidate sets from the servers on its UNL and votes on every transaction. Transactions with enough “yes” votes move to the next round; those without are discarded or carried into the next ledger’s candidate set.

The final round requires at least 80% of the server’s UNL to agree. Everything that clears that bar is applied to the ledger, and the ledger is closed. The earlier rounds use rising thresholds, which helps the network notice slow servers that keep up at low thresholds but fall behind as the bar rises.

Why 80% gives a one-fifth tolerance

If a transaction needs 80% of a UNL, a fraudulent transaction can only be approved if enough servers on that list are dishonest to supply the missing votes. The paper writes the strong-correctness condition as the number of faulty servers being at most (n − 1) / 5. For a UNL of 101 servers, that is 20 faulty servers. By our arithmetic, a wrongly approved transaction would then need roughly 81 faulty servers on that list, which is the paper’s weaker bound of (4n + 1) / 5.

The authors note that this is not the strongest tolerance in the literature. They list the classic limit of fewer than one third faulty servers for Byzantine agreement, a variant called FaB Paxos at one fifth, and a result by Attiya, Dolev and Gill at one quarter. Their argument is that the design adds other useful properties, mainly low latency, and that a double-spend attempt that slips through consensus still fails, because transactions are applied deterministically and the second spend finds no funds left.

They also give a probability view. If each member of a UNL has some independent chance of joining a cartel, the chance that a cartel exceeds one fifth shrinks quickly as the list grows. Their example: with a 15% individual chance and a UNL of 200 servers, the probability that consensus stays correct is about 97.8%. The real-world assumption behind that is that servers are cryptographically identifiable, so a list can be chosen across countries, industries and interests that are unlikely to conspire.

The fork problem and the overlap rule

Correctness for one server does not guarantee agreement across the network, because different servers can have different UNLs. The paper’s example is two cliques of servers, each larger than a fifth of the network, that trust only each other. Each clique could reach a valid 80% consensus on its own, and the network would split into two different last-closed ledgers.

The remedy is connectivity. The paper gives a sufficient condition: for every pair of servers, the overlap between their UNLs should be at least one fifth of the larger list (their Equation 3). Below that, a fork is possible in principle; at or above it, two groups cannot both reach 80% on conflicting sets. The authors point out that the overlap may even include faulty servers, so long as the total number of faulty servers stays within the strong-correctness bound.

Keeping it moving: latency and housekeeping rules

To make sure rounds end, the paper adds practical rules. Servers that respond slower than a preset bound are removed from UNLs. There is a mandatory two-second window for proposing initial candidate sets, which sets a floor of about two seconds per round but gives reasonable servers time to take part. Servers that vote “no” on everything, or keep proposing transactions that never validate, can be flagged and removed. A network-split detection step helps servers notice if they have drifted onto a disconnected group.

The authors also supply a curated default UNL chosen to keep the collusion probability low, while encouraging users to build their own. They include simulation code that starts with half the servers saying yes and half no, then shows how repeated adjustments converge once the 80% threshold is reached.

What to take from it

Our reading: the paper is honest about its main assumption. The proofs hold only if the UNL bounds are met, and the discussion section says that satisfying them “requires management” of everyone’s lists and some monitoring of the network’s overall structure. In other words, trust is not removed; it is moved into list selection. That is a very different trade-off from proof of work, and also from the quorum slices in the Stellar Consensus Protocol, where each participant also chooses whom to wait for, but the groups are formed and combined differently.

For readers evaluating any ledger that uses a trusted-list design, the useful questions are: who is on the default list, how diverse are they, how much do different users’ lists overlap, and who watches the overlap. They overlap with the checks in our seven questions for crypto projects. For the current protocol and its claims, use the more recent analysis the authors point to rather than this draft.