Hashgraph Development: Understanding the Algorithm Before You Build on It

Hashgraph is a consensus algorithm, invented by Leemon Baird, in which nodes gossip events to each other and then compute a fair, final transaction order by "virtually voting" on the shared history, without sending vote messages. Developing with hashgraph means understanding that ordering model, because it shapes what your application can rely on.

This page is about the algorithm itself: how it reaches consensus, what guarantees it gives and where those guarantees end. If you want the practical side of shipping an application on the public network that runs it, see the companion guide to Hedera development and its services.

Gossip about gossip

In most blockchains, a leader proposes a block and others vote on it. Hashgraph has no leader and no blocks. Each node repeatedly picks another node at random and sends it everything it knows that the other node does not. Every sync creates a new event, which records:

• any new transactions the creator wants to submit,
• a timestamp from the creator's clock,
• the hash of the creator's own previous event (the self-parent),
• the hash of the last event received from the node it just synced with (the other-parent),
• the creator's signature.

Because each event points to two parents, the events form a directed acyclic graph: the hashgraph. The key insight is that the graph records not just transactions but who heard what from whom, and when. That is the "gossip about gossip".

Virtual voting

Since every honest node eventually holds the same graph, each node can calculate how every other node would vote in a classic Byzantine agreement protocol, purely from the graph's structure. No actual vote messages cross the network. The procedure, simplified:

1. Divide into rounds. An event's round is determined by whether it can "strongly see" (reach through paths covering a supermajority of nodes) enough witnesses from the prior round.
2. Identify witnesses. The first event each node creates in a round is that round's witness.
3. Decide fame. Later witnesses virtually vote on whether each earlier witness was seen by most of the network quickly. Witnesses with a supermajority "yes" are famous.
4. Order events. Once a round's famous witnesses are decided, events they all received get a round-received number and a consensus timestamp: the median of the times at which those famous witnesses' creators first learned of the event.
5. Apply transactions. Every node applies the transactions in the same consensus order, so all states match.

The median timestamp is what gives hashgraph its "fair ordering" property: a single malicious node cannot easily push a transaction ahead of another, because the timestamp reflects when the network as a whole saw it.

What guarantees you get

Two caveats matter. First, aBFT is only as strong as the distribution of stake among node operators: one third of weight under common control breaks the guarantee. Second, "fair" means fair relative to when the network received a transaction. It does not stop a node operator from seeing a transaction early and submitting its own; it narrows the window rather than eliminating front-running entirely.

Licensing and the open-source status

Early criticism of hashgraph focused on patents held by Swirlds, the company Baird co-founded. That situation changed. The Hedera governing council acquired the hashgraph intellectual property and the codebase was released under the Apache 2.0 license, and the code has since been contributed to the Linux Foundation Decentralized Trust as the Hiero project. For a builder, this means you can study, fork and run the consensus implementation without a commercial license, though running your own production network is a serious operational undertaking.

Building with hashgraph: your realistic options

Very few teams implement the algorithm from scratch, and you probably should not either. Consensus code is extraordinarily hard to get right, and subtle bugs surface only under adversarial network conditions. Your practical paths are:

• Build on the public Hedera network. The most common route. You submit transactions to a network governed by a council of organizations and receive aBFT finality in a few seconds. This is covered in the Hedera development guide.
• Run a private network from the open-source code. Useful for research or for a consortium that wants hashgraph ordering among known members. Compare this honestly with other private blockchain options, which have larger operator communities.
• Use hashgraph as an ordering service. Submit messages to a consensus topic and let your own application process them, which gives you a tamper-evident, timestamped log without putting your business logic on-chain.

Hashgraph versus other DAG designs

Hashgraph is often lumped together with other DAG-based ledgers, but the designs differ a lot. Some DAGs (such as the original IOTA Tangle) had each transaction approve earlier ones and relied on a coordinator for years. Others combine a DAG for data dissemination with a separate BFT protocol for ordering. Hashgraph uses the DAG itself as the input to a deterministic voting procedure. The broader landscape is laid out in the guide to directed acyclic graph ledgers.

When hashgraph makes sense

Choose hashgraph-based infrastructure when you need fast, final ordering with fair timestamps: audit logs, supply-chain events, ticketing, sequencing of bids in an auction, or high-volume micropayments. Look elsewhere when your product depends on deep composability with Ethereum-native DeFi liquidity, or when your users need permissionless validation that they can personally participate in today.

Frequently asked questions