What is Hedera?

Introduction

For the token explainer, see HBAR.

Hedera is a public distributed ledger built around the hashgraph consensus algorithm rather than a conventional blockchain. That difference matters because most people approach new networks with a familiar template in mind: transactions are grouped into blocks, miners or validators compete to propose them, and finality is either probabilistic or delayed. Hedera starts from a different design question: *what if the network could agree on order and timestamps without block production, and without repeated voting messages flooding the network? *

That question leads to most of what makes Hedera distinctive. It leads to a consensus mechanism based on gossip-about-gossip and virtual voting. It leads to a system that emphasizes fast finality, predictable fees, and native services for tokens and consensus messages. And it also leads to a governance and node-operation model that has historically looked less like open participation from day one and more like a staged attempt to reach decentralization over time.

To understand Hedera well, it helps to hold two ideas together at once. The first is technical: Hedera is trying to solve distributed agreement efficiently and with strong finality guarantees. The second is institutional: Hedera is also trying to make that system legible and stable enough for enterprises and long-lived applications. Much of the network’s design only makes sense when you see both goals operating together.

How does Hedera reach consensus without blocks?

The easiest way to misunderstand Hedera is to think of it as just another smart-contract chain with different branding. The core mechanism is not “Ethereum, but faster.” The underlying idea is that the network does not need to package transactions into blocks and then have participants explicitly vote on those blocks in a series of rounds. Instead, each node continually shares information with other nodes, and the history of who told whom what becomes part of the consensus data itself.

In Hedera, the basic unit is an event. An event contains transactions and also includes hashes of two earlier events: one created by the same node and one received from another node during gossip. Because each event points backward in this way, the network builds a directed acyclic graph, or DAG, called the hashgraph. The important consequence is not the graph for its own sake. The consequence is that the graph records the communication history of the network.

That communication history is the key. In many distributed systems, nodes must send extra voting messages to decide whether some proposed block should count as accepted. Hedera’s claim is that if every node can reconstruct enough of the communication graph, then they can infer how votes would have been cast without needing to send those votes explicitly. That is what virtual voting means. The votes are not imaginary in the sense of being optional; they are implicit in the shared structure of the hashgraph.

So the compression point is simple: Hedera tries to turn communication history into consensus evidence. Once that clicks, the rest of the design becomes easier to follow.

How does Hedera’s gossip-about-gossip protocol spread and record transactions?

Ordinary gossip protocols spread information by having nodes repeatedly tell random peers what they know. This is a familiar tool in distributed systems because it is robust and tends to spread data quickly without requiring central coordination. Hedera adds a twist: when a node gossips, it does not just send transactions. It also creates an event that records the parent relationships showing where that knowledge came from.

That is why the phrase is gossip-about-gossip. The network is not only sharing application data; it is also sharing metadata about the spread of that data. If node A learns something from node B and later tells node C, the resulting event structure preserves that ancestry. Over time, every honest node can reconstruct a very similar picture of the overall information flow.

This matters because consensus is fundamentally about knowledge: who knows what, who knows that others know it, and when enough of the network can be confident that a fact has become common knowledge for practical purposes. Hedera’s hashgraph tries to encode exactly that progression. The graph is not a decorative alternative to blocks. It is the mechanism by which nodes estimate when a transaction has been seen widely enough, in a pattern strong enough, that its place in the ledger can be fixed.

The whitepaper and official materials emphasize that this approach achieves asynchronous Byzantine Fault Tolerance, or aBFT. In ordinary language, that means the protocol is designed to keep working even if some participants act maliciously and even if message delays are unpredictable. The system does not rely on a known upper bound for network delay. That is a stronger model than the partially synchronous assumptions used by many practical consensus systems.

It is worth being precise here. aBFT does not mean the network becomes magically immune to every real-world failure mode. Software bugs, operational mistakes, and application-layer vulnerabilities can still cause serious problems. Hedera’s 2023 smart contract exploit is a useful reminder: the consensus layer can have strong guarantees while software above or around it can still fail in costly ways. Consensus safety is not the same thing as total system safety.

How does virtual voting produce fast, deterministic finality on Hedera?

The phrase virtual voting can sound mystical until you restate it mechanically. Suppose all honest nodes eventually see essentially the same communication graph. If the graph contains enough information to determine how a node would vote about the order or fame of certain events, then each node can compute those votes locally. There is no need to transmit separate vote packets because the evidence required for the vote is already present in the graph.

That design aims to save bandwidth and reduce coordination overhead. Instead of broadcasting both transactions and many rounds of explicit consensus votes, the network broadcasts events, and those events carry the information needed to derive consensus. Hedera’s materials argue that this produces high efficiency and fast finality because the protocol spends less effort on extra consensus chatter.

For a user, the visible result is deterministic finality in seconds rather than the looser “wait for more confirmations” pattern common on some chains. Official Hedera materials describe the ledger state as updating with finality once consensus is reached, and developer documentation describes deterministic finality in roughly 2–3 seconds for smart contract transactions. That is an important distinction from proof-of-work systems like Bitcoin, where finality is probabilistic and grows stronger with additional blocks rather than arriving as a crisp yes-or-no state.

A concrete example helps. Imagine two exchanges submit transfers at nearly the same time, and both want confidence that their transaction order cannot later be reversed by a reorg. On a chain with probabilistic finality, they may wait through several block confirmations because a longer competing chain could still appear. On Hedera, the promise is different: once the consensus algorithm assigns order and timestamp and the transaction reaches finality, the application can treat that order as settled rather than tentatively settled.

That difference is why Hedera often positions itself for payments, token transfers, and messaging-style use cases where timely certainty matters more than simply raw throughput. Fast agreement is not just about speed for its own sake. It changes what kinds of applications can rely on the ledger without building their own waiting room on top of it.

What does Hedera mean by “fair” ordering and timestamps?

Hedera’s technical materials make a notable claim beyond safety and speed: fairness. This deserves care because “fairness” in distributed systems is always partly about what exactly is being measured. Hedera’s claim is not that every user gets identical outcomes or that malicious actors cannot gain any advantage. The narrower idea is that transaction ordering and timestamps should be less vulnerable to manipulation by a leader, miner, or block producer who has unusual control over inclusion order.

Because Hedera does not center consensus around a single proposer assembling a block, it argues that no one participant should have the same kind of privileged ordering power found in leader-based systems. Consensus timestamps are derived from the network’s view of when transactions became known, rather than simply from one proposer’s local clock or discretionary ordering choices. In theory, that should reduce some forms of transaction-order manipulation.

This is one place where analogy helps, if used carefully. A block proposer is a bit like an editor deciding what appears first on a front page; even with rules, the editor has practical discretion. Hedera is trying to replace that model with something more like reconstructing the order in which many reporters independently saw the news spread. The analogy explains why Hedera talks about fairness. It fails, however, because distributed consensus still depends on protocol rules, timing, and adversarial assumptions; it is not a social process with human judgment removed.

The practical point is modest but meaningful: Hedera is designed to reduce proposer-style ordering power by making order emerge from shared communication history. Whether that is enough for every MEV-sensitive or adversarial use case is a separate question. But it is a real architectural difference.

What native services does Hedera provide and why do they matter?

Many readers first encounter Hedera through its consensus claims, but developers usually encounter it through its services. Hedera’s official materials consistently describe three primary services: smart contracts, token service, and consensus service. These are not just marketing categories. They reflect a deeper design choice about where functionality should live.

On Ethereum, many things are implemented as smart contracts because the base layer is intentionally general and relatively minimal. On Hedera, more functionality is provided as native network services. That changes performance and developer tradeoffs. If token creation and transfer are offered by a built-in Hedera Token Service, the network can optimize that path directly rather than making every token operation pay the full flexibility cost of arbitrary contract execution.

That is why Hedera can make strong claims about token throughput and fixed transfer pricing for native token actions. Official Hedera documentation says token transfers can reach 10,000 transactions per second and cost a fixed $0.0001 USD paid in HBAR. Whatever one thinks of the exact performance envelope in production, the architectural point is clear: Hedera prefers fixed-function native services where that produces simpler, faster, and more predictable behavior.

The same logic explains the Hedera Consensus Service. Not every application needs on-chain computation. Some just need an ordered, timestamped stream of messages that many parties can trust. Hedera exposes that directly, letting applications use the network as a shared ordering layer without forcing every use case into the smart-contract model.

This is a meaningful contrast with general-purpose chains. Hedera is not saying “everything should be a contract.” It is saying that some common jobs (tokenization, ordering, file-like storage, account management) work better when the network treats them as first-class functions.

How compatible are Hedera smart contracts with Ethereum’s EVM?

Hedera does support Solidity and the Ethereum Virtual Machine through an optimized Besu EVM. That makes it easier for EVM developers to port tools and code. But compatibility is not sameness, and some of the most important lessons about Hedera come from the edges of that compatibility.

Developer documentation frames this as EVM equivalence rather than identity. The goal is that developers can point familiar tooling at Hedera-supported RPC endpoints and use similar workflows. But smart contract execution occurs within a system that also has native entities, native token behavior, and Hedera-specific authorization rules. So the network can look familiar at the contract layer while behaving differently at the system boundary.

The 2023 precompile exploit showed exactly why that boundary matters. The issue was not that hashgraph consensus failed. The issue was that a delegatecall path into an HTS precompile allowed one contract to act with another contract’s credentials in a way that should not have been possible. In effect, the vulnerability emerged where EVM semantics interacted with system-level token logic. Hedera responded by changing the security model so that smart contracts could no longer use that pathway, and by tightening authorization around contract actions, allowances, and explicit ContractId-based permissions.

That episode is important because it illustrates a general rule: when a network combines native services with EVM compatibility, the seams matter. Those seams can be a source of efficiency and better UX, but they also create special cases that developers need to understand. In Hedera, smart contracts are powerful, but many important operations remain shaped by native service rules rather than pure Ethereum assumptions.

How is Hedera’s governance different from other Layer 1 networks?

If the consensus design is the most technically distinctive part of Hedera, the governance design is probably the most debated. Hedera is governed by the Hedera Council, described in official sources as a body of up to 39 global organizations with equal voting rights and term limits. Council members operate nodes in the current permissioned model and vote on upgrades, pricing, treasury management, and related decisions.

The rationale is straightforward even if one disagrees with it. A public network meant for enterprises and long-lived applications needs predictable governance, transparent decision-making, and some guard against capture by a charismatic founder or concentrated validator cartel. Hedera tries to get that by spreading governance across large institutions from different regions and industries, with equal votes and published minutes.

But the tradeoff is equally straightforward. This is not the same as open, permissionless governance by anonymous participants. If the set of node operators is permissioned and upgrade approval runs through a council of vetted organizations, then the trust model is more institutionally managed than on networks where anyone can join consensus directly. Hedera openly describes itself as currently public and permissioned, with a path toward becoming public and permissionless over time.

That “path” matters because it is not yet the same as completion. Official materials say the network intends to broaden node operation and coin distribution over time, but the exact thresholds and timeline for full permissionless participation remain less concrete in the provided sources. So the accurate picture is neither “fully centralized” nor “already fully permissionless.” It is a network whose decentralization story is partly present and partly aspirational.

Whether that is a bug or a feature depends on what problem you think a ledger should solve. If you want maximal open participation from day one, Hedera’s model may look too controlled. If you want a network that large organizations can treat as operationally stable and governable, the same model may look like a practical compromise.

What is HBAR used for, and how do staking and fees work on Hedera?

Hedera uses proof of stake, and the native asset is HBAR. In the whitepaper’s design, stake weight matters for consensus security, and the fee system is divided into node, network, and service components. Early network design also involved treasury proxy-staking more than two-thirds of HBAR to Council-hosted nodes during the initial phase, which reflects again that Hedera began from a managed rollout rather than immediate open validator competition.

Economically, the important thing is not just that HBAR exists, but what jobs it performs. It pays for network usage, participates in staking security, and anchors the fee model. Hedera also emphasizes predictable fees, often quoting fiat-denominated prices for certain services while payment is made in HBAR. That is meant to reduce the operational uncertainty developers feel on networks where gas costs can swing sharply with congestion.

The deeper design principle is that Hedera wants cost predictability to be part of the product, not an accidental byproduct. That makes sense if your target users include businesses budgeting for millions of API-like interactions. It is less aligned with the culture of open-ended fee markets where blockspace is auctioned aggressively during peak demand.

There is, however, a genuine open question behind the polished surface: how fee schedules and node-level economics evolve as the network moves further toward broader node participation. Fixed and predictable fees are easier to promise in a more managed environment. They become harder to sustain if the system eventually relies on more open competition among heterogeneous operators. That does not make the model incoherent, but it does mean some of its long-run economics depend on future governance choices.

What are Hedera mirror nodes and how do they differ from consensus nodes?

A subtle but important part of Hedera’s architecture is the mirror node system. Mirror nodes do not participate in consensus. Instead, they ingest record files and signature files produced by consensus nodes, verify them, store historical data, and expose that data for querying. Official documentation presents them as a cost-effective way to access public ledger history without burdening the consensus network itself.

This split tells you something important about Hedera’s design priorities. Consensus nodes are there to agree on order and state transitions. Mirror nodes are there to make that history usable at scale for wallets, explorers, analytics systems, and applications. In other words, Hedera separates agreement from observation more explicitly than some systems do.

The trust model follows that separation. Mirror nodes inherit trust through consensus-node signatures, chains of hashes, and state proofs; they are not themselves consensus authorities. That makes them closer to indexed observers than validators. It also makes Hedera easier to integrate for data-heavy applications that need historical queries but do not need to burden the consensus path with every read.

If you are used to blockchain explorers that reconstruct state by indexing blocks, this will sound familiar in purpose but somewhat different in implementation. Hedera’s record-file pipeline, cloud distribution, and mirror ingestion process reflect an architecture built around high-throughput ordered records rather than block-by-block chain traversal.

Is Hedera open source, and can its ledger be forked?

Hedera’s stance on openness has changed over time, and that history explains some otherwise confusing source material. Earlier whitepaper-era materials described an open review model with defensive patent use to prevent forks that might confuse users about the “real” ledger. More recent official materials say Hedera is now fully open source, and that the codebase has been contributed to the Linux Foundation Decentralized Trust as Project Hiero.

That shift matters because it changes how outsiders can inspect, contribute to, and build on the software. It also softens one of the longstanding criticisms of Hedera’s original posture. At the same time, Hedera still places unusual emphasis on ledger continuity and protection against deceptive forks through signed state proofs, address book history, and governance controls. That reflects a persistent institutional priority: the network wants a strong answer to the question, “Which ledger is the authoritative continuation?”

On some networks, contentious forks are accepted as part of the ecosystem’s politics. Hedera has generally treated them as a threat to trust and enterprise adoption. You do not have to share that value judgment to see its coherence. If your target user is a multinational company integrating settlement rails, ambiguity about canonical continuity is not a charming feature of decentralization.

When is Hedera a good fit and what tradeoffs should you consider?

Hedera makes the most sense when the application values four things at once: fast finality, predictable fees, native token functionality, and institutionally managed governance. That combination is well suited to payment rails, tokenized assets, auditable event ordering, and applications that want public-ledger properties without inheriting every volatility of open mempool politics and highly variable execution costs.

Its assumptions matter most when you move outside that comfort zone. If your benchmark for decentralization is open validator entry and minimal governance discretion, Hedera will feel constrained. If your application requires arbitrary smart-contract composability as the dominant design center, Hedera’s preference for native services may feel less flexible than chains that push more functionality into contracts. And if you blur the distinction between consensus guarantees and total platform safety, you can overestimate what aBFT protects you from.

The smart-contract exploit in 2023 is useful here not as a dismissal of Hedera, but as a reality check. Strong consensus guarantees did not prevent an application-platform bug from causing losses and emergency operational intervention, including disabling proxies to stop further theft. That tells you two things. First, Hedera’s system can respond quickly through coordinated governance. Second, coordinated governance itself is part of the trust model, including the ability to take emergency action that would be politically or technically harder on some other networks.

Conclusion

Hedera is best understood as a public ledger that tries to make agreement itself more efficient by replacing block production and explicit voting rounds with a hashgraph of communication history and virtual voting. Around that core, it builds a network optimized for fast finality, predictable fees, and native services such as tokenization and consensus messaging.

What makes Hedera distinctive is not one isolated feature but a package of choices. It pairs strong consensus claims with a more managed governance structure, EVM compatibility with native system services, and public access with a historically permissioned node model. If you remember one thing tomorrow, remember this: Hedera is a ledger designed less around open-ended block competition and more around efficient ordering, operational predictability, and governed continuity.

How do you buy Hedera (HBAR)?

Buy HBAR on the spot market using Cube Exchange by funding your account and placing a spot order. On Cube you can fund with fiat (USD) or a supported crypto transfer, then trade the HBAR/USD or HBAR/USDC market using a market or limit order depending on your price needs.

1. Fund your Cube account with fiat via the on-ramp or deposit a supported stablecoin (for example USDC) or HBAR from an external wallet.
2. Open the HBAR/USD or HBAR/USDC spot market on Cube Exchange.
3. Choose an order type: use a market order for immediate execution or a limit order to control your entry price and avoid slippage.
4. Enter the HBAR amount (or USD/USDC spend), review estimated fill, fees, and price, then submit the order.