Three Ways to Agree: Ripple, Stellar and Hedera Consensus Compared

The question every network answers

A shared ledger needs every honest participant to end up with the same list of transactions in the same order, even if some participants fail or cheat. Bitcoin answers with mining, where the longest chain of work wins. The three designs here answer differently, and each one asks participants to trust something specific.

We use each project’s own words as sources: a 2014 research draft from Ripple, a 2016 draft from the Stellar Development Foundation, and a description on Hedera’s own website. None is an independent audit, so this comparison is about ideas, not endorsements.

Ripple: listen to a list

In the 2014 draft, each server keeps a Unique Node List, the set of other servers whose votes it counts. Servers vote on candidate transactions in rounds, and in the final round a transaction needs at least 80% of the list to agree. The authors derive a tolerance of up to one fifth faulty servers in a list, and a condition on how much different servers’ lists must overlap to prevent a fork. The authors have since stated that the draft no longer reflects the current protocol. Our Ripple consensus explainer goes through it in detail.

Stellar: listen to your slices

In the Stellar Consensus Protocol, each node picks groups of other nodes it is willing to rely on, called quorum slices. Because each node chooses its own slices, there is no central list. Safety comes from the way chosen slices overlap. The approach is called federated Byzantine agreement, and our Stellar explainer covers it.

Hedera: gossip and virtual voting

Hedera describes its network as based on the hashgraph algorithm, a directed acyclic graph rather than a chain of blocks. Nodes spread signed events by “gossip about gossip”, and each node calculates what others would vote from the graph itself, which Hedera calls virtual voting, so no separate voting messages are needed. Hedera describes the algorithm as asynchronous Byzantine fault tolerant, stating a tolerance of up to one third of malicious nodes, and says that once consensus is reached it is final.

Transaction order is set by when a supermajority of nodes received each transaction, and the consensus timestamp is the median of those receipt times. Consensus weight is proportional to the HBAR staked to each node, and Hedera says an attacker would need to control more than one third of the total HBAR supply. It also says the network is overseen by a council of global enterprises. Those are Hedera’s own descriptions.

Side by side

Why the numbers are not directly comparable

“One fifth” in the Ripple draft refers to faulty servers within a particular node’s list, given an 80% rule. “One third” in Hedera’s description refers to malicious nodes or staked weight in an asynchronous setting. Stellar’s answer has no single figure because it depends on how nodes choose their slices. Three different fractions of three different things.

Our reading: each design is honest about where the trust sits, even if the headline fraction hides it. For Ripple’s draft, the authors say outright that its guarantees require management of everyone’s lists and some monitoring of network structure. For Hedera, trust sits partly in how stake is distributed and who sits on the council. For Stellar, it sits in the slices each participant picks.

What to ask next

Who chooses the lists, slices or council, and could they change over time? How concentrated is the staked weight? Is there independent analysis, and is it recent enough to describe today’s software? Early drafts like Ripple’s and Stellar’s are valuable for understanding design intent, but later papers, code and audits are what describe what runs now. See also our seven questions for crypto projects.