What Is a Hashgraph and How Does It Work?

A hashgraph is a type of distributed data structure and consensus algorithm designed to help a network of computers agree on the order of transactions. Instead of packaging transactions into a single chain of blocks, it records a graph of signed events showing what each network node learned and when it learned it.

The best-known implementation is Hedera, a public distributed ledger that uses Hashgraph consensus. However, the terms are not interchangeable: Hashgraph is the consensus technology, Hedera is a network that uses it, and HBAR is Hedera’s native cryptocurrency.

This distinction matters because many introductions blur the technology, network, and token into one idea. This guide explains each part, walks through the consensus process, compares Hashgraph with blockchains, and examines its genuine strengths and tradeoffs without price predictions or “blockchain killer” claims.

What Problem Does Hashgraph Solve?

A distributed ledger is copied across multiple computers, often called nodes. Because there is no single database server deciding what happened, those nodes need a consensus mechanism—a set of rules for agreeing on which transactions are valid and the order in which they occurred.

The challenge is that messages do not reach every node at the same time. Connections can be delayed, computers can go offline, and some participants may behave dishonestly. A useful consensus system must allow honest nodes to reach the same result despite those complications.

Hashgraph addresses that problem by spreading information through a gossip protocol and preserving the history of that communication. Nodes can then use the shared history to calculate consensus locally instead of transmitting a separate stream of voting messages.

What Is a Hashgraph?

A hashgraph is a directed acyclic graph, or DAG, made from events. “Directed” means the relationships point backward to earlier events. “Acyclic” means following those relationships cannot create a loop. Each event can contain transactions along with several pieces of information about its place in the communication history.

A timestamp supplied by the node creating the event
One or more transactions or other messages
A hash pointing to the node’s previous event, called the self-parent
A hash pointing to the latest event received from another node, called the other-parent
A digital signature proving which node created the event

Those parent hashes connect events into a graph. The graph records more than the transactions themselves: it also records “who told whom” about the information. That communication history is the basis of Hashgraph’s virtual voting process.

How Hashgraph Consensus Works

The full algorithm involves rounds, witnesses, strong seeing, fame decisions, and mathematical rules for ordering events. A simplified transaction journey makes the basic process easier to understand.

Step 1: A Client Submits a Transaction

A user or application creates and signs a transaction, then submits it to a network node. The node performs preliminary checks, such as verifying signatures and confirming that the payer can cover the required fee. Passing this initial check does not yet mean the transaction has reached consensus.

Step 2: Nodes Gossip Information

Each node repeatedly selects another node and shares the information it knows. The receiving node later shares its expanded knowledge with another participant. This is called a gossip protocol because information spreads in a pattern similar to a rumor moving through a group.

The process can spread data quickly because informed nodes communicate in parallel. It does not require one central broadcaster to deliver every transaction to every participant.

Step 3: “Gossip About Gossip” Builds the Graph

After two nodes synchronize, each creates an event containing parent hashes that identify the relevant earlier events. Those links preserve the communication history. This additional information is why the method is called gossip about gossip: nodes share transactions and a compact record of how that knowledge has circulated.

As gossip continues, honest nodes receive the same events and reconstruct compatible copies of the hashgraph. Network delays can cause their temporary views to differ, but additional communication fills in the missing history.

Step 4: Nodes Calculate Virtual Votes

Traditional Byzantine fault-tolerant systems may exchange dedicated voting messages. Hashgraph reduces that extra communication because the graph already shows which events each node could have known about.

Every honest node applies the same rules to the same graph and calculates how participants would vote. No imaginary votes are broadcast across the network; “virtual” means the result is derived locally from the recorded event ancestry.

The algorithm divides events into rounds and identifies certain first events as witnesses. Later witnesses determine whether earlier witnesses are “famous,” a technical status used to establish which events were widely observed. Users do not need to perform these calculations themselves, but the concepts explain how the network moves from an unordered graph to an agreed sequence.

Step 5: The Network Assigns Consensus Order and Time

Once the relevant famous witnesses are known, each node calculates when an event was received and assigns it a consensus timestamp. Hedera’s documentation describes this timestamp as a median derived from when the event reached the applicable network participants. Using a median reduces the influence of an individual node reporting an unusually early or late time.

Events are placed in a deterministic order using their round received, consensus timestamp, and a cryptographic tie-breaker. Because honest nodes use the same graph and rules, they reach the same ordered result without a leader choosing the next block.

Step 6: Transactions Update the Ledger State

After consensus, transactions are applied in the agreed order. Account balances, tokens, smart contracts, or other ledger data are updated consistently across the nodes. At that point, the transaction has finality under the network’s consensus rules.

What Is Asynchronous Byzantine Fault Tolerance?

Hashgraph is designed to provide asynchronous Byzantine fault tolerance, commonly shortened to aBFT. Byzantine fault tolerance means honest participants can reach agreement even when some participants fail or act maliciously. “Asynchronous” means the safety of the agreement does not depend on assuming that messages will arrive within a fixed maximum time.

This property operates under defined assumptions. In the original Hashgraph paper, the proof assumes secure digital signatures, collision-resistant hashes, eventual delivery between honest members, and fewer than one-third of the relevant voting weight acting maliciously. On Hedera, consensus influence is stake-weighted rather than simply one vote per computer.

aBFT does not mean that every application built on the network is automatically secure. Bugs in smart contracts, stolen private keys, malicious applications, dishonest data sources, and poor operational security remain possible.

Hashgraph vs. Blockchain

Hashgraph and blockchain are both approaches to maintaining a distributed ledger, but they organize data differently. Comparisons should be made carefully because “blockchain” includes many architectures and consensus systems. Bitcoin’s proof of work, Ethereum’s proof of stake, and permissioned enterprise blockchains do not have identical performance, energy use, or governance.

Feature	Hashgraph	Blockchain
Data structure	A graph of cryptographically linked events	Transactions grouped into sequential blocks
Information flow	Nodes gossip events and their communication history	Varies by network; blocks and transactions propagate among peers
Consensus	Virtual voting calculated from the event graph	Varies, including proof of work, proof of stake, and BFT protocols
Leader or block producer	No leader selects the next event for consensus	Many networks select a miner, validator, or proposer for each block
Finality	Deterministic once consensus order is assigned	May be probabilistic or deterministic, depending on the network
Energy profile	No proof-of-work mining	Ranges from energy-intensive proof of work to efficient proof of stake
Public-network example	Hedera	Bitcoin, Ethereum, Solana, and many others

If these terms are still blending together, start with our guide to the difference between blockchain and cryptocurrency. Our expanded blockchain terminology glossary also explains nodes, hashes, digital signatures, ledgers, smart contracts, and finality.

Hashgraph, Hedera, and HBAR Are Different Things

Hashgraph is the data structure and consensus algorithm.
Hedera is a public proof-of-stake distributed ledger that implements Hashgraph consensus and offers network services.
HBAR is the network’s native cryptocurrency. It is used to pay transaction fees and contributes to consensus security through staking.

Hedera also supports Solidity smart contracts through Ethereum Virtual Machine compatibility, native token services, and a consensus service for creating ordered and timestamped application messages. Hashgraph consensus is therefore one layer of the broader Hedera platform rather than an application by itself.

How Hedera Governance Works

Hedera is governed by the Hedera Governing Council, which is designed to include organizations from different industries and regions serving limited terms. Council responsibilities include network governance and software-related decisions.

This model differs from token-holder governance, informal developer-led governance, and proof-of-work networks. Supporters argue that identifiable institutions can provide operational stability and accountability. Critics may prefer open validator participation or a governance model with less formal institutional control.

It is therefore more accurate to describe the governance design and node-access model than to declare the network simply “centralized” or “decentralized.” Hedera’s current public materials describe consensus-node operation as permissioned. Readers evaluating the network should check the current node list, council membership, software governance, stake distribution, and plans for broader participation rather than relying on an old roadmap.

Performance Claims Need Context

Hedera currently advertises approximately 10,000 transactions per second for its public network and three-to-five-second finality. These are network-published figures, and they should not be treated as a universal speed for every workload.

A simple token transfer, a consensus-service message, and a complex smart-contract call require different amounts of computation. Published throughput may reflect a particular transaction category, software version, hardware configuration, or test condition. Real application performance also depends on client infrastructure, API providers, network throttles, contract complexity, and demand.

The same caution applies when comparing with other ledgers. A headline TPS number does not measure decentralization, finality, security assumptions, storage requirements, smart-contract execution, or developer experience. Useful comparisons define exactly what is being processed and under what conditions.

Potential Uses for Hashgraph-Based Networks

Hashgraph consensus can support many of the same broad application categories as other distributed ledgers. Whether it is the right choice depends on the trust model, performance requirements, costs, compliance needs, and available development tools.

Ordered audit trails: Applications can submit document hashes or messages to create a verifiable sequence without placing the private source data directly on a public ledger.
Payments and token transfers: Fast finality and predictable ordering can be useful when applications need to know that a transfer has settled.
Asset tokenization: Networks can represent fungible tokens or unique digital assets, subject to technical, legal, and issuer-specific controls.
Supply-chain records: Participants can timestamp events and verify that later records have not replaced earlier ones. The ledger still cannot guarantee that the original real-world input was truthful.
Application coordination: Multiple organizations can use an agreed message order when no single participant should control the shared record.
Smart contracts: Developers can build programmable applications, although contract security and code quality remain separate concerns from consensus security.

Advantages of the Hashgraph Approach

No proof-of-work mining: Consensus does not depend on miners repeatedly performing energy-intensive computations.
Efficient vote calculation: Nodes derive virtual votes from information already contained in the graph rather than broadcasting a separate message for every vote.
Deterministic ordering and finality: Once consensus is reached, applications do not wait for an increasing number of block confirmations.
No single block-proposal leader: Nodes gossip events in parallel instead of relying on one participant to construct the next block.
Consensus timestamps: Ordering is based on a network-derived timestamp rather than one node unilaterally setting the final order.

Limitations and Tradeoffs

Smaller ecosystem: Hedera has fewer applications, developers, infrastructure providers, and integrations than the largest blockchain ecosystems.
Permissioned consensus nodes: The current node model is a meaningful governance and decentralization consideration.
Stake concentration: Because consensus influence is stake-weighted, the distribution of HBAR matters to network security.
Complexity: Gossip, event ancestry, rounds, witnesses, and virtual voting can be harder to explain and independently evaluate than a simple block chain.
Public-ledger privacy limits: A tamper-resistant record is not automatically confidential. Sensitive data often needs encryption, access controls, or off-ledger storage.
Garbage in, garbage out: Consensus can establish what data was submitted and its order, but it cannot prove that an external sensor, person, or organization supplied truthful information.
Token risk: Technical capabilities do not establish a fair HBAR price or guarantee investment returns.

For a broader look at how networks make collective decisions, read our guide to blockchain consensus mechanisms.

Is Hashgraph Better Than Blockchain?

There is no universal winner. Hashgraph offers an efficient leaderless consensus design, deterministic ordering, and no proof-of-work mining. A blockchain may offer a larger ecosystem, different governance, broader validator participation, stronger network effects, or a trust model better suited to a particular application.

The better question is: Which architecture meets the requirements of this application? Developers and organizations should compare security assumptions, node participation, finality, transaction types, actual workload performance, fees, privacy, regulatory needs, tooling, and governance.

Frequently Asked Questions

Is Hashgraph a blockchain?

No. Both are distributed-ledger approaches, but Hashgraph organizes signed events as a DAG rather than grouping transactions into a linear sequence of blocks.

Is every DAG a hashgraph?

No. A DAG is a general type of data structure. Hashgraph is a specific consensus design that uses a DAG of events, gossip about gossip, and virtual voting.

Does Hashgraph use proof of work?

No. Hashgraph consensus does not use competitive mining. Hedera operates as a proof-of-stake network, with HBAR stake contributing to the consensus weight of nodes.

Can someone use Hedera without buying HBAR as an investment?

Applications need HBAR to pay network transaction fees, but that is a utility requirement rather than an investment recommendation. Developers can experiment with test HBAR on Hedera’s test network before using the production mainnet.

Does Hashgraph make data private?

Not automatically. Consensus and tamper resistance address agreement and record integrity. Privacy requires separate choices involving encryption, permissions, key management, and what data is placed on the ledger.

The Bottom Line

Hashgraph is a consensus approach that turns a history of node-to-node communication into a shared graph. Gossip spreads signed events, parent hashes preserve who learned what, and virtual voting lets nodes calculate consensus from that history. The resulting order can be finalized without proof-of-work mining or a leader selecting the next block.

Hedera is the main public network using this technology, while HBAR pays network fees and contributes to proof-of-stake security. Hashgraph has credible technical strengths, but those strengths do not eliminate questions about governance, node access, ecosystem size, privacy, data quality, or token risk. Understanding those distinctions produces a more useful picture than simply calling it faster or better than blockchain.