The Hedera network uses the hashgraph consensus algorithm, a system that determines how thousands of independent computers agree on transactions without any central coordinator. The algorithm is based on the two main mechanisms: gossip about gossip and virtual voting.
In this article, you’ll find out how hashgraph consensus works, why Hedera processes transactions the way it does, and how Hedera’s consensus algorithm actually impacts your experience when swapping or providing liquidity on platforms like SaucerSwap.
What Is Hedera’s Consensus Algorithm?
Hashgraph is Hedera's consensus algorithm. It functions as both a distributed consensus algorithm and the data structure used to record how transaction information spreads across the network.
This record helps nodes see which transactions were passed from one single node to another, when they were received, and how widely they spread. Using this information, Hedera nodes can reach consensus, which ultimately determines the transaction’s final place in the network record.
Is Hedera a Blockchain?
Technically, no. Blockchain networks group transactions into blocks, and each new block is connected to the previous one, forming an ordered chain of blocks.
Hedera organizes data through hashgraph consensus into a structure called a Directed Acyclic Graph (DAG). In this structure, multiple events are linked together in parallel, they don’t form one chain. Hedera and blockchain networks refer to the distributed ledger technology aiming to resolve the same issue: how to make a network of separate computers agree on one common record of transactions.
Still, the underlying data structure and hashgraph consensus approach differ, and this difference is what lets Hedera achieve some of its performance characteristics, such as faster transaction finality compared to Ethereum and other networks.
Why Consensus Matters in Distributed Ledger Technology
Hashgraph consensus is the main challenge of any decentralized network, and Hedera's hashgraph distributed ledger is no exception. You have thousands of computers spread around the world with no central server. However, they all must share an identical understanding of the transaction record.
Moreover, certain computers might have a slower connection, while others fully disconnect. The consensus algorithm is what helps the Hedera network still reach agreement despite these issues.
How the Hashgraph Consensus Algorithm Works
When you submit a transaction, whether it's a token swap or deploying smart contracts on Hedera, it goes through a specific sequence of steps before it's finalized:
- Nodes share transaction data through gossip
- Events form the hashgraph data structure
- Nodes calculate votes locally based on shared history
- The network reaches hashgraph consensus
Each step is explained in detail below.
Step 1. Nodes Share Transaction Data Through Gossip
You submit a transaction, and it reaches one of Hedera's nodes. The node first performs preliminary checks, such as verifying the transaction signature. These checks help ensure the transaction is eligible for processing.
If the transaction passes these checks, the node starts sharing information about it with other nodes. These then pass on the data to more nodes, and thus, the process continues throughout the network.
Many of these syncs happen in parallel across the network, so information spreads quickly. This is called a gossip protocol.
Step 2. Events Form the Hashgraph Data Structure
Every time two nodes sync, that sync creates what Hedera calls an event. An event is a small data package that usually contains:
- The transactions being communicated
- A timestamp
- Two hashes
- A digital signature from the node that created the event
The resulting structure is the hashgraph itself: a record of how information has spread across the Hedera network over time. Every node constructs and updates its own local copy, giving the consensus algorithm a shared foundation to work from. And since gossip ensures that every node eventually receives the transaction information, all copies converge toward being identical.
Step 3. Virtual Voting Lets Nodes Calculate Votes Locally
At this point, nodes have built very similar copies of the same hashgraph. Now, the network needs to reach an agreement on the transactions.
As nodes share information through gossip, they gradually build matching copies of the hashgraph. Each node can use this shared history — the basis of distributed consensus in hashgraph — to understand what the other nodes know and when they learned it. Node A looks at the hashgraph, sees when Node B learned about the transaction relative to other events, and can calculate how Node B would vote from that information. Node B does the same for Node A.
Once enough information has been shared across the network, every node performs the same calculation and reaches the same result — the consensus timestamp and final order of each transaction.
Step 4. The Network Assigns Consensus Timestamps and Order
At this stage, nodes have already calculated the same result independently. Now the network reaches the ultimate agreement. Once the transaction has its hashgraph consensus timestamp and position in the order , it becomes part of Hedera’s official record.
Gossip About Gossip Explained
Besides the gossip protocol, Hedera has a second layer of communication. While regular gossip means nodes share transaction data with each other, gossip about gossip means they also share the history of how this data traveled through the network.
Say Alice sends a transaction, it’s submitted to a Hedera node, and that node shares it with Bob’s node. Later, Bob’s node shares the information with Carol’s node. When it does, it doesn’t just pass along the transaction data. It also includes information about where it received the transaction from. When Carol’s node later shares information with Dave’s node, Dave receives the transaction along with the history of how it spread through the network.
This is what the two hashes inside each event represent. One hash points to the previous event created by the same node. The other points to the most recent event received from another node during gossip. Together, they create a traceable record of who communicated with whom and in what sequence.
Why is this important? Without knowing how information spreads across the network, nodes wouldn’t be able to vote virtually and achieve consensus.
What Is Virtual Voting in Hedera?
The term refers to each node performing the same calculation locally based on its own copy of the hashgraph. The term "voting" is used because, ultimately, results are similar: the network reaches agreement.
In a typical consensus algorithm mechanism, voting works this way:
- Each node forms an opinion about how transactions should be ordered and sends its vote to other nodes.
- These votes are then gathered by these nodes, counted up, and all the nodes decide the outcome.
When there are more nodes within the network, more messages must be exchanged, which can make this process slower. Let’s sum up the main differences between virtual and regular voting:
Why Hedera’s Hashgraph Is aBFT
What happens if some nodes act maliciously? A node could withhold information during gossip or communicate only with specific nodes. This issue is known as the Byzantine Generals Problem, named after the Byzantine Generals thought experiment, in which generals can’t trust each other's messages.
The solution is to design a system capable of achieving the right agreement even if some members are dishonest or inactive. A system that can do this is called Byzantine fault-tolerant, or BFT.
Hedera accounts for malicious participants by design and even takes this a step further. Its hashgraph is not just BFT but aBFT. aBFT stands for asynchronous Byzantine fault tolerant.
The majority of BFT systems need the messages between nodes to come within a certain time frame. If these messages are delayed, the system might halt progress until communication becomes normal again.
Hedera's hashgraph doesn't depend on such time windows. Even if messages are delayed or arrive out of order, the hashgraph consensus algorithm keeps working towards the correct outcome.
This is possible thanks to how the hashgraph data structure organizes the history of the network. Every event contains hashes linking it to previous events, so when a delayed message finally arrives, nodes can see exactly where it fits in the sequence. All of this works as long as more than two-thirds of the network’s stake is held by honest participants.
Hashgraph Consensus Timestamping and Fair Transaction Order
A hashgraph consensus timestamp is the time Hedera assigns to a transaction once the network has agreed on it. It’s calculated as the median of the times each node first received this transaction.
Transactions with earlier consensus timestamps usually appear first in the final sequence. So, as the order is decided together by the network, Hedera sets itself apart from systems where a block producer can affect the order of transactions within a block.
This is especially vital in DeFi, where each transaction can influence the following one. When you’re exchanging tokens on, for example, SaucerSwap, a trade that is processed immediately before yours could change the pool's price and impact your exchange outcome.
Hedera Consensus Service vs. Hashgraph Consensus Algorithm
Hashgraph consensus algorithm is the core mechanism of the Hedera public network. HCS is a service that lets applications use that same ordering system for their own messages.
With HCS, an app can create a topic, which is like a channel for messages. Each created topic comes with its own ID. When the app sends messages to the topic, Hedera assigns each message a Hashgraph consensus timestamp and a sequence number, so that all people are able to view the precise order of these messages. Later, apps or users can read these ordered messages through a mirror node.
The Hedera Consensus Service is useful when an app needs a trusted, verifiable timeline of messages. Hedera orders and timestamps the messages, while the app decides what those messages mean and how to use them.
Hashgraph vs Blockchain Consensus
Because hashgraph is often compared with blockchain, it helps to look at the main differences side by side. Blockchain networks can work very differently from one another, so this table focuses on broad patterns:
Why Hedera’s Hashgraph Consensus Matters for SaucerSwap and DeFi
SaucerSwap is a decentralized exchange and liquidity protocol built on Hedera, and the properties of hashgraph consensus have direct implications for anyone using it, whether you need to buy HBAR safely, exchange tokens, or provide liquidity. Each of these actions benefits from what consensus delivers at the network level:
- Fast finality: The entire process can take up to five seconds.
- Fair transaction ordering: Through consensus timestamping, the order is decided by the network collectively, which helps create a more consistent Hedera DeFi experience.
- Low fees: Hedera’s fees are low mainly due to its fee model, but the consensus algorithm also plays a part: since nodes calculate votes locally and, thus, don’t have to send extra voting messages across the network, this helps reduce the network's operating costs.
Key Terms to Know
- Hedera — a public distributed ledger technology powered by the hashgraph consensus algorithm, with low fees and fast finality.
- Blockchain — a type of distributed ledger that groups transactions into blocks linked in a linear chain.
- Gossip about gossip — the way nodes share the history of how data travels through the network.
- Consensus timestamp — the time Hedera assigns to a transaction after reaching agreement, calculated as the median of the times when each node first received the transaction.
- Virtual voting — the process within a hashgraph where nodes calculate agreement locally using the shared hashgraph. This happens without needing to send actual vote messages across the network.
- Asynchronous Byzantine fault tolerant — a security standard describing a system that reaches correct consensus even if some nodes act maliciously or go offline, and even if messages are delayed or arrive out of order.
- Hashgraph — Hedera's distributed consensus algorithm and data structure, created by Dr. Leemon Baird. It relies on gossip about gossip and virtual voting to reach consensus.
- SaucerSwap — a decentralized exchange and liquidity protocol built on Hedera that offers fast finality and predictable fees.
FAQs About the Hedera Consensus Algorithm
Is Hedera blockchain?
Hedera and blockchain networks like Ethereum are distributed ledger technologies, but they work differently. Blockchain networks chain blocks in a linear sequence. Hedera uses hashgraph, a DAG-based structure where multiple events can be recorded simultaneously rather than one after another, which contributes to faster finality.
How fast are transactions on Hedera?
Usually, transactions are completed in about three to five seconds. For native token and consensus services, the network can handle up to 10,000 transactions per second in its current configuration, though the actual throughput depends on network activity and the type of transaction being processed.
How does gossip about gossip differ from regular gossip?
Unlike regular gossip, it includes information about how the data traveled through the network, which creates a shared history that makes virtual voting possible.
Why doesn't Hedera need actual voting to reach consensus?
Because every node has the same hashgraph consensus, they all see the same communication history. This shared view is what makes distributed consensus possible without any vote messages crossing the network — each node calculates the result independently, making traditional voting unnecessary.
Why does transaction ordering matter in DeFi?
Transaction ordering plays a role in DeFi since the order in which transactions are processed can affect the outcome. For example, a swap that goes through just before yours could affect the results of your trade.
Conclusion
Hedera's hashgraph consensus algorithm relies on three connected mechanisms:
- Through the gossip protocol, nodes spread transaction data across the network.
- Nodes also share the history of who communicated what and when.
- Through voting, nodes use the history to calculate agreement locally, without sending additional messages.
As a result, the network typically reaches finality within seconds while maintaining fair ordering. These are the properties that make Hedera a compelling foundation for DeFi exchanges like SaucerSwap.
Check out Hedera's documentation for additional information. And if you want to experience Hedera-powered DeFi in action, start by exploring SaucerSwap docs.
