Skip to content

LibraryConsensus2016Design paperCorpus record

The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance

Hedera. Leemon Baird.

Baird's technical report on hashgraph: gossip about gossip, a virtual vote computed from the graph, and a fairness claim about the order of transactions. Hedera is the later public network that uses the algorithm under a governing council.

Hashgraph has every node gossip about gossip, weave those events into a graph, and run a virtual vote on that graph so that, in the paper's model, nobody has to send a vote.

The five-minute read

Gossip about gossip

A node tells a random peer everything it knows, including whom it has already told. The history of that gossip is a directed graph. The graph is the input to consensus.

Virtual voting

Because every node can compute the same graph, each node can calculate how the others would have voted. The paper's claim is that the ballots do not need to cross the network.

Fairness is ordered by receipt

The paper defines a timestamp from when an event reached a supermajority, and it orders transactions by that time. The fairness claim is this definition, not a general promise about markets.

The set is permissioned in the core argument

Virtual voting assumes you know who the members are. An open membership race is a different problem. Hedera's later council and permissionless work should not be back-dated into the proof.

Asynchronous Byzantine fault tolerance is the target

The paper argues safety without a leader and without a round timeout as the primary tool. The argument depends on the gossip graph eventually connecting. Partitions still delay the moment a supermajority sees an event.

One action, walked through

  1. A node creates an event: a payload of transactions plus hashes of two parent events, one from itself and one from a peer.
  2. It gossips that event, and the events the peer is missing, to a random other member.
  3. Each member inserts received events into the hashgraph and computes rounds, witnesses and famous witnesses under the paper's rules.
  4. A famous witness is one that later rounds can all see. Virtual voting decides fame locally.
  5. Transactions that are ancestors of famous witnesses in the required way receive a consensus timestamp and an order.

The argument, unpacked

Seeing is the vote

The protocol counts whether a later witness can strongly see an earlier one through enough other members. That graph relation is the ballot. If two honest nodes compute different graphs, they are not in the protocol anymore. Sync of the graph is the honesty of the implementation.

Fair ordering is not MEV resistance

Ordering by median time of receipt among members is a specific fairness definition. A leader who sequences a public mempool for profit is a different architecture. Do not cite hashgraph as a solution to builder profits on a chain that still has a builder.

Bandwidth is the cost moved, not removed

Virtual voting saves a ballot round. Gossip about gossip still ships the graph. A small permissioned set can do this. A very large set is shuffling a lot of history. The paper's performance claims belong to the set size it has in mind.

What has to be true

  • Membership is known, and more than two thirds of members follow the protocol.
  • Gossip eventually reaches a supermajority. A lasting partition prevents fame from being decided.
  • Every honest node applies the same deterministic function to the same graph.
  • Payloads inside events are valid under some application rule the consensus layer does not invent.

What happened after the paper

Hedera built a network around this algorithm, with a governing council and later opening moves that are outside the 2016 paper. Patent and licensing history also sits outside the algorithm. The study here is of the virtual-voting construction, not of a token or a council seat.

What to check before you use the idea

  • Is the member set known, and how does it change?
  • What fraction of members must gossip an event before it can be famous?
  • Does the application need the paper's fair timestamp, or only a total order?
  • Are performance numbers quoted for a small named set or for an open network?

Terms

Event
A vertex in the hashgraph: transactions plus hashes of two parents, signed by the member who created it.
Gossip about gossip
Exchanging not only transactions but the history of who talked to whom, so the graph can be reconstructed.
Famous witness
An event that later rounds agree was seen by enough of the set. Fame is decided by virtual vote.
Virtual voting
Computing, from the graph, how members would have voted, so those votes are not sent.

The problem the paper names

Voting protocols send votes. Baird's claim is that if every node gossips the history of who told whom, the votes can be calculated from that history and do not need to be sent.

What the design proposes

  • Events contain transactions plus hashes of earlier self-events and received events. The data structure is the hashgraph.
  • Seeing, and strongly seeing, are defined on that graph. Famous witnesses are decided from those relations.
  • Ordering uses a median of timestamps from famous witnesses, which is the paper's fairness device.

How the mechanism is specified

  • The argument assumes a known set of nodes and a bound on the fraction that are Byzantine.
  • Virtual voting saves the vote messages only if the gossip really delivered the parent hashes.
  • Fair ordering in the paper is a property of that timestamp median, not a general promise about markets.

What this page does not treat as proven

  • The report is not Hedera's council charter, fee schedule or token terms.
  • A permissioned set of gossip peers is load-bearing. Opening the set changes the theorem you are allowed to quote.
  • Fairness here does not mean a user received a good price.

Why a venture studio still reads it

Read this when someone says 'our consensus is fair' . Ask whether they mean Baird's timestamp median over famous witnesses, or a marketing adjective. Those are not the same sentence.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.