How does Hedera's hashgraph consensus differ from a blockchain?

A blockchain orders transactions by having one producer at a time propose a block, then getting everyone else to agree on it. Hashgraph, the algorithm behind Hedera, skips the proposer entirely. Every node gossips small signed events, each event records who it heard from, and from that shared history every node independently calculates the same order and the same timestamps, without ever sending a vote. The result is asynchronous Byzantine fault tolerant (aBFT) consensus with finality in a few seconds and a fair, timestamped order of transactions.

Events instead of blocks

The unit of data in a hashgraph is an event, created by one node. Each event contains:

Field	Purpose
Transactions	Zero or more client transactions the node wants to submit
Self-parent hash	Hash of this node's own previous event
Other-parent hash	Hash of the latest event received from the node it just synced with
Timestamp	When the creator made the event
Signature	The creator's signature over the event

Because each event references two parents, events form a directed acyclic graph (the "hashgraph") instead of a single chain. There is no block producer, no leader election and no mempool competition for block space. Every node is creating events all the time.

Gossip about gossip

Nodes sync by picking a random peer and sending it every event the peer doesn't have yet. The receiver then creates a new event recording that sync: its self-parent is its own last event, and its other-parent is the sender's last event.

That's gossip about gossip. The network isn't just spreading transactions. It spreads a record of who told whom what, and when. After a few rounds of syncing, every honest node has almost the same graph, and each node knows not only what it has seen but what every other node had seen at each point.

Virtual voting

Classical BFT protocols send explicit vote messages, which gets expensive as the node count grows. Hashgraph uses virtual voting: since each node holds a copy of everyone's history, it can calculate how any other node would vote, based on what that node had seen. No vote messages cross the wire.

In outline:

1. Events are grouped into rounds. The first event a node creates in a new round is a witness.
2. For each witness, later witnesses "vote" on whether it was seen widely and quickly enough to be famous. Votes are computed from the graph, not sent.
3. A decision requires a supermajority of more than two-thirds of stake. Once the famous witnesses of a round are decided, every event they can reach gets a place in the consensus order.
4. Each event's consensus timestamp is the median of the times at which the nodes first received it.

Using the median means no single node, or minority of nodes, can shift a transaction's timestamp by lying. This gives Hedera its fair ordering property: a node can't easily reorder transactions it doesn't like or insert its own ahead of others. That's a meaningful contrast with leader-based chains, where the block producer chooses ordering, which is where MEV comes from.

aBFT and finality

Asynchronous BFT is the strongest class of BFT: consensus is guaranteed even if messages are delayed arbitrarily, as long as less than one-third of the stake is malicious. Many BFT chains are only partially synchronous and rely on timing assumptions for liveness.

Finality is deterministic. Once a transaction has a consensus timestamp, it is final, with no reorgs and no confirmation counts. On Hedera mainnet this typically takes a few seconds.

Hedera also groups ordered transactions into record files it calls blocks (HIP-415), mostly so EVM tooling that expects block numbers keeps working. Those blocks are a packaging of already-agreed transactions, not the unit of consensus.

Governance and the node set

Hedera mainnet is run by the Hedera Governing Council, a group of large organisations (up to 39 members, with term limits) that operate consensus nodes, set network policy and approve software upgrades. Node weight comes from HBAR staked to each node, including HBAR that ordinary accounts stake to nodes for rewards.

The node set has been permissioned from launch, with a stated plan to move toward permissionless nodes over time. The codebase is now open source and was contributed to the Linux Foundation as the Hiero project. How far the network has opened is still changing, so check Hedera's current announcements before relying on it.

The network services

Hedera exposes several native services, each priced separately:

Service	What it does
HBAR / crypto service	Accounts, transfers, allowances, staking to nodes
Hedera Token Service (HTS)	Native fungible tokens and NFTs, with optional admin, freeze, KYC, pause and custom-fee keys, without deploying a contract
Hedera Consensus Service (HCS)	Ordered, timestamped messages on a topic, for audit logs or ordering an off-chain system
Smart Contract Service	An EVM that runs Solidity, reachable through a JSON-RPC relay so MetaMask, Hardhat and ethers work
File service	Small files stored on-ledger, used for contract bytecode and system configuration

Contracts can call HTS through system contracts, so an ERC-20-style interface can sit on top of a native token.

HCS is the simplest way to see consensus timestamps in practice. With the JavaScript SDK:

import {
  Client,
  PrivateKey,
  TopicCreateTransaction,
  TopicMessageSubmitTransaction,
} from "@hashgraph/sdk";

const client = Client.forTestnet().setOperator(
  process.env.OPERATOR_ID!, // e.g. "0.0.1234"
  PrivateKey.fromStringED25519(process.env.OPERATOR_KEY!),
);

const create = await new TopicCreateTransaction()
  .setTopicMemo("order events")
  .execute(client);
const topicId = (await create.getReceipt(client)).topicId!;

const submit = await new TopicMessageSubmitTransaction({
  topicId,
  message: "order #42 accepted",
}).execute(client);

const record = await submit.getRecord(client);
console.log(topicId.toString());
console.log(record.consensusTimestamp.toDate());
console.log(record.receipt.topicSequenceNumber?.toString());

Every subscriber sees messages on that topic in the same order, with the same timestamps.

Fees in US dollars

Hedera fees are set in USD and paid in HBAR. The council maintains an on-ledger exchange rate, and the network converts each fee at payment time. A simple HBAR transfer is priced at a fraction of a cent. Because there is no auction for block space, fees don't spike under load. Instead, the network throttles transaction types at fixed capacity limits. That predictability is a large part of Hedera's enterprise pitch.

The account model

Hedera accounts are not just public keys:

• Account IDs look like 0.0.12345 (shard.realm.number). Each account also has an EVM address, and ECDSA-keyed accounts can use their Ethereum-style address as an alias.
• Accounts must be created by a transaction, which someone pays for. Sending HBAR to an unused alias or EVM address auto-creates an account (lazy creation), and the sender covers the cost.
• Keys are rotatable. An account's key can be changed, and keys can be ED25519, ECDSA secp256k1, or threshold and key-list structures, so multisig is native.
• Token association. An account must be associated with an HTS token before it can hold it, which limits spam. Accounts have a configurable number of auto-association slots, and recent network changes allow unlimited auto-association for new accounts created this way. Check the setting on any account you airdrop to.

Hashgraph vs a typical PoS blockchain

	Hedera hashgraph	Typical PoS blockchain
Data structure	DAG of events	Linear chain of blocks
Who orders transactions	Nobody; order is computed from the graph	Current block proposer
Voting	Virtual, computed locally	Explicit signed attestations
Fault tolerance	aBFT, below one-third malicious stake	Usually partially synchronous BFT or longest-chain
Finality	Deterministic, a few seconds	Ranges from seconds to minutes, sometimes probabilistic
Fair ordering	Median timestamps limit manipulation	Proposer can reorder; MEV
Fees	Fixed in USD	Market-based, spikes under congestion
Validator set	Council-run, permissioned, opening over time	Usually permissionless
Accounts	0.0.x IDs, created explicitly, rotatable keys	Address derived from key

Summary

Hashgraph replaces block proposal and explicit voting with gossip about gossip and virtual voting. That gives Hedera aBFT consensus, deterministic finality in seconds, and median-based timestamps that make ordering hard to manipulate. The trade-offs sit outside the algorithm: a council-governed node set that is only gradually opening, and an account model that needs explicit creation and token association. For EVM developers most code carries over, but plan for account IDs, associations and HTS rather than assuming Ethereum's model.