Hedera is a public ledger network, and HBAR is the coin that network runs on. The documentation says early on that this is not a blockchain. A sentence like that is either a boast or a disclosure, and the only way to tell is to work through what it changes for one ordinary transaction, what it costs to build a network that way, and which number in the running network shows the cost. Everything below is arranged around those three questions, and one rule is kept throughout: no claim taken from marketing material is repeated here as fact. Wherever something could be checked, the figure came from the public API that anyone can query, and the exact endpoints are listed so you can run the same reads yourself.

1. A network whose own documentation says it is not a blockchain

Start with the sentence itself. A blockchain collects transactions into a block, one participant publishes that block, and the block points back at the one before it. The resulting chain is the order. Hedera does none of that. There is no block, nobody publishes one, and the order is computed by every node from a shared record of who learned what and when. So the sentence in the documentation is right about what it describes, and what it describes is the data structure.

The statement stops there, at the data structure. How open the participation is, and who holds power over the rules, are separate questions, and on both of those this design sits further from open than Bitcoin does. Marketing copy tends to run the data-structure claim and the decentralisation claim together, as though the first one settled the second.

That matters more here than with most coins. In write-ups about this network, a claim about the consensus algorithm, a claim about throughput and a claim about corporate adoption tend to appear in the same paragraph, and nothing in the paragraph tells you which one is a fact about the software and which one is a sales line. The first kind can be checked against the documentation and the live network. The second kind cannot be checked at all.

One clarification before the mechanics. The network is open to use. Anyone can create an account, hold HBAR and send transactions, and nobody approves that. The closed part is the consensus layer, which is the set of machines that decide the order. Those two facts get merged constantly in both directions, by supporters who say the network is open and by critics who say it is private.

2. What the nodes pass around when nobody publishes a block

You submit a transaction to a node. That node wraps what it currently knows into an item called an event. An event holds the transactions the node has taken in, a timestamp from that node’s own clock, and two references: the last event the node created itself, and the last event it received from whichever peer most recently talked to it. Those two references are what lets any node reconstruct the order later.

The node then picks another node at random and sends its recent events. That node does the same to someone else, passing along what it just learned along with the references attached to it. The algorithm’s name for this is gossip about gossip. The name is literal: the data being passed around includes the history of the passing around.

After a short interval every node holds the same record: which node received which event, from which peer, and where that sits relative to everything else that node knew at the time. Nodes reach this state at slightly different moments, and events keep arriving, so the structure grows at the edges while the older part stops changing.

Fixing an order requires the participants to agree on which events came first, and in most designs that means one machine proposes and the others answer. Here every node already holds the same record, and the procedure for deciding is deterministic. So a node can run that procedure on its own copy and work out how every other node would have answered, without any of them sending an answer. That is called virtual voting. Nothing is being simulated in a loose sense: the calculation produces the same result the messages would have produced, from data the node already has, so no vote messages cross the network. The cost sits on the other side: every node keeps and processes the whole record.

Two values come out for each transaction. One is its place in the order. The other is a consensus timestamp, derived from the times the individual nodes recorded when they first saw the transaction. On a chain, that time comes from whoever published the block.

3. Settled by rule or settled by odds: what changes for one transaction

If you have ever withdrawn coins to an exchange you have seen a counter on the deposit screen saying something like three of six confirmations. That counter exists for a specific reason. On networks where miners publish blocks, the order is whatever chain has the most accumulated work behind it, and a competing chain built in parallel can replace the most recent blocks. Each additional block makes that replacement more expensive and therefore less likely. It never makes it impossible.

This has happened on live networks. Litecoin had a stretch of thirteen blocks replaced, and Bitcoin Cash had a two-block replacement. Both networks kept running afterwards, which is the point: a replacement is one of the outcomes the rules allow. The confirmation counter is the exchange pricing that possibility and deciding how much of it to accept. If your deposit has not been credited yet, that counter is usually the answer.

Hedera has no such counter, because there is nothing to count. The order comes out of a computation every node runs on the same record, so spending more money buys no ability to change it. Once the procedure fixes a transaction’s position and its consensus timestamp, waiting longer leaves both values where they are, and every later state of the network keeps that same history. This is the thing the design genuinely buys, and it is not oversold.

The rule holds under a stated assumption about how many participants can misbehave, and that assumption carries a condition this article works through further down. Inside it, the position and the consensus timestamp are settled, and settled is what they stay.

For an ordinary user sending coins to a friend, the practical difference is small: a few seconds either way. It gets large when a business needs to know which of two records came first when they arrived milliseconds apart, and needs an answer that will not be revised. The design was built around that use case.

4. Claims you will hear about Hedera, and what the record supports

Most of what circulates about this project in English falls into one of six statements. For each one, the documentation and the API either back it up or they do not.

The third row is where the project’s own phrasing gets borrowed for an argument it does not make. Saying there is no block is a description of how data is arranged. Turning that into a claim about openness requires an extra step that nothing in the design supports, and the extra step points the wrong way: the set that decides the order here is smaller and better identified than on a network where the participants cannot be counted.

5. Reading the network yourself: what the public API returned

Every changing figure in this article came from one place: the public mirror node, a read-only API that returns the network’s state as JSON. It needs no key and no account. The base address is https://mainnet-public.mirrornode.hedera.com/api/v1, and these are the paths used here.

Throughput was measured from the last of those. Take one hundred consecutive transactions, look at the spacing between their consensus timestamps, convert to transactions per second, and repeat the whole read three times to avoid reporting one odd window. The result is a demand measurement, and it reads differently at a different hour.

That last row measures how busy the network was while the reads were running, and it is the row most often quoted for something else. It does not measure what the software can do, and it is not offered as a complaint about speed. Every network in this field has a wide gap between its stated ceiling and its observed load, and there is nothing damning about that. The problem is the habit in coin write-ups of quoting the ceiling as though it described the traffic. Quote the ceiling when you are talking about capacity, not when you are talking about traffic.

The same exercise settles a different question along the way. If a stranger can read account balances, transaction histories and staking settings from a public endpoint without identifying themselves, then this is not a network built to conceal what happens on it. Every figure in the table came out of exactly that kind of anonymous read.

6. Asynchronous, and the condition attached to “fewer than one third”

The algorithm is classified as asynchronous Byzantine fault tolerant, usually shortened to aBFT. Read the three parts separately and the label stops being jargon.

Asynchronous means the proof makes no assumption about how late a message can arrive. Messages may be delayed or arrive in a scrambled order, and the result still holds. Byzantine means the participants may do worse than crash: they may send different things to different peers, lie about what they heard, or coordinate with each other. Fault tolerant means the honest remainder still arrives at the same order regardless. The threshold is fewer than one third of the participating nodes. The proof was published, and the proof itself was checked mechanically.

The condition attached to that threshold does the work here. To say fewer than one third, you have to be able to count. Counting requires knowing who the participants are. A network whose participant set changes whenever somebody plugs in a machine has no fixed denominator to divide, so it states safety as a probability that improves with time.

So the guarantee and the membership list are one design decision seen from two sides. Remove the list and the theorem stops applying. Keep the list and you have given up the property that anyone can join the set that decides. There is no version of this where you get the rule without the list, and any description that states the rule without the list is incomplete.

The theorem covers agreement on order among the nodes. It does not cover which rules those nodes enforce, or who decides those rules. Both of those come down to who is on the list and how the list is governed, which is the next section.

7. The price of counting participants: a node list with operator names on it

Query the network’s node endpoint and you get a list. Each entry carries an identifier, a public key, a stake figure, and a description field. The description is not a technical string. It reads as the operator’s name and the city the machine sits in. The list includes entries hosted by LG in Singapore, by Swirlds in Iowa, by Nomura in Tokyo, by Google in Helsinki, and by Zain Group in Kuwait City. Every entry on it is run by a member of the governing council.

None of that is leaked or inferred. It is published because it has to be. If the safety argument depends on counting participants, the participants have to be identifiable, and identifying them means saying who they are. A network that both counts its members and hides them would be making a claim nobody could check.

Rule changes, the fee schedule and the handling of the treasury are decided by the Hedera council, which is made up of more than thirty organisations. The two principles its own documents state are that members hold equal voting rights and that membership carries a term limit, both aimed at stopping any single member from controlling outcomes. The membership list itself changes over time, so treat any specific roster you read anywhere as a snapshot.

This is more spread out than a network where one company or one foundation decides and everyone else watches. It is also clearly different from a network where anyone who shows up can take part in setting the rules. Both are true, and picking whichever one supports your prior is how people end up arguing past each other about this project.

There is one conclusion the node list does not support, and it is the most common mistake made about this network in English. Seeing a familiar corporate name on the council tells you that the company takes part in governance, and in some cases that it operates a machine. It does not tell you that the company runs any part of its business on the ledger. The node list carries operator names and nothing beyond them.

One more thing belongs in this section, because it is about who controls the software rather than who controls the machines. The consensus algorithm was patented, and for years that was the central criticism of the project: a public network running on technology one company owned. The council acquired the intellectual property, the implementation was released under the Apache 2.0 licence, and the core network software is now developed as an open project under the Linux Foundation. The patent objection described a situation that has since changed. What has not changed is who takes part in consensus, and that is the list at the top of this section.

8. Where HBAR sits: every coin existed on the first day

Fifty billion HBAR, written out as 50,000,000,000, came into existence when the network launched. Nothing has been created since. There is no mining, there are no block rewards, and there is no scheduled reduction in issuance for the simple reason that there is no issuance to reduce. If you have read that you can produce this coin with hardware, that is wrong at the level of the design.

Because nothing is issued, the total never grows. Networks that pay for security with new coins raise their total on a schedule, and this one has no such schedule. The same rule takes something away on the other side: there is no budget of new coins to pay anyone for running infrastructure. On mining networks the new coins are the payment that keeps machines pointed at the chain. Here the cost of running consensus nodes sits with the organisations that operate them, and the incentives that do exist come out of balances that already exist.

Part of the total has never entered circulation. It sits in the treasury and comes out on a schedule the council publishes in advance. Coins that have yet to circulate are a dilution factor for anyone holding today, and pretending otherwise would be dishonest. A published release plan is also better than an undisclosed one, and both of those sentences hold at the same time. The exact share released so far is a number that moves, so it is in the snapshot table instead of in this paragraph.

The starting line was different from Bitcoin’s. The initial distribution ran through purchase agreements with qualified investors, so a large share of the supply started out in a few hands. That is a fact about origins, and readers can weigh it however they like. What it does explain is why the treasury schedule matters more here than on a network where coins were emitted to whoever showed up with hardware.

The practical consequence for a reader is short. There is no way to produce HBAR yourself. You buy it on an exchange, the same way you would buy Bitcoin, or you are paid it, the way you would with most assets.

9. Staking that never moves your coins, and the ceiling on what it pays

You hold HBAR in an account. You set one field on that account to the identifier of a node. From that moment your balance counts toward that node’s stake. Your coins do not move, you keep the keys, and nothing is transferred to a contract or a validator. The documentation is explicit that there is no lock-up period and that a staked balance stays liquid, so you can spend or sell at any moment without unstaking first, waiting out a queue, or paying an exit fee. That is a genuine convenience, and it is unusual.

Accounting runs in 24-hour staking periods. Rewards accrue per completed period, so pointing an account at a node for an afternoon does nothing. Unclaimed rewards stay collectable, and the documentation caps the backdated claim at 365 days, so an account left alone for years collects one year’s worth at most.

The reward rate has a ceiling, and it is where expectations usually break. There is a maximum reward rate per HBAR per day, set as a network parameter by the council, and it is low by design. The figure is published in tinybars, the smallest unit of the coin, at 100 million tinybars to one HBAR, and the value read from the API is in the snapshot table. There is also a cap on the total paid out per day across the whole network, and a cap on how much stake earns rewards at all.

One distinction that saves confusion later. What an exchange calls staking or earn is the exchange’s own product, with its own terms, its own custody arrangement and its own rate. It is not the same thing as pointing a self-custodied account at a node, even when the coin is the same. Our explainers on what staking is and on exchange earn products cover that split in more detail.

10. Rewards come out of a funded account, not out of new coins

Since no coins are created, staking rewards have to come from coins that already exist. They come from a system account with the identifier 0.0.800, and you can query its balance exactly the way you would query any other account on the network. Nothing about that account is special except its role.

On networks that fund staking through issuance, the reward is created on demand, so the rate can be set by policy and paid indefinitely, with the cost spread across every holder through supply growth. Here the reward is bounded by the balance of one account and by the council’s decisions about topping it up. The rate is a parameter someone sets, and it has to be conservative because the source is a balance that is finite by construction.

What that does not license is a prediction. The council can top the account up, so today’s balance says nothing about how long rewards last. The structural point stands on its own: the source of rewards on this network is a funded account, and that is a different arrangement from the one most staking coverage assumes.

It also means cross-network yield comparisons mislead more than usual. A headline rate paid in newly created coins comes out of supply growth, and a capped rate paid from a fixed reward account comes out of a balance the council has to keep topped up. A table that puts the two percentages side by side hides that difference.

11. Fees are set in dollars and paid in HBAR

Fees on this network are quoted in United States dollars and settled in HBAR. The documentation publishes a schedule per operation: a coin transfer is listed at a hundredth of a cent, and opening an account at five cents.

Three things about that table matter more than the individual numbers. The prices are denominated in USD and paid in coin, so the dollar cost of an operation stays put while the number of coins it consumes moves with the coin’s price. The schedule itself lives in a system file, identified as 0.0.113, and governance can change it, so the schedule is a published parameter with a process behind it. And the conversion from the dollar amount to a coin amount uses an exchange rate the network maintains for that purpose only. That rate exists to price fees. It is not a market quote and nothing in this article treats it as one.

A company that wants to put the cost of a million operations into next year’s budget can do the arithmetic from the table above and be right, because the dollar figure per operation is fixed by the published schedule rather than by how busy the network is. On networks where fees float with congestion and with the coin’s price at the same time, the same arithmetic turns into a guess.

12. What the network sells, and whether selling more of it needs more HBAR

The token service lets you create and move tokens using network features directly, without writing a contract. Issuing a token, minting, and transferring are operations with listed prices rather than programs you deploy and pay gas for. That removes a category of bugs, and it also removes a category of flexibility, which is a trade some builders take and others refuse. Alongside it the network runs contracts in an environment compatible with Ethereum tooling, so contracts and developer tools written for that ecosystem work without being rewritten.

The consensus service is the one that shows what this network is. You submit a message to a topic and the network returns an order and a consensus timestamp for it. The message can be a hash or a reference, so the underlying records stay in your own system. What you are buying is ordering and timing, which is exactly what the consensus algorithm produces, sold directly. The price for one message sits in the same published schedule as everything else, at $0.0008.

The fee structure and the supply structure have to be read together, because together they raise the hardest question about the coin. Fees are set in dollars. Supply is fixed and nothing is issued. If usage doubles, the dollars collected roughly double, and the number of coins that pass through those fees depends on what the coin is worth at the time. A higher coin price means each transaction consumes fewer coins. The revenue the network collects is therefore steady in dollars and variable in coins, and that denomination is what breaks the usual link between usage and coin demand.

So the familiar sentence, more enterprise usage means more demand for the coin, does not follow automatically from this design. There are paths by which it could hold. Accounts need a balance in order to pay anything at all, businesses may keep a working balance, and coins committed to staking are held rather than traded. None of those paths shows up in the public API, so this stays an open question rather than a finding.

13. My read on this design, and the part I cannot settle

The design is internally consistent, and I do not say that about many projects. If you want an order that is fixed by rule instead of by probability, you need a threshold. A threshold needs a count. A count needs a membership list. The list is what the fixed order costs, and the project did not hide the connection: the operator names sit in the API in plain text, where anyone can read them. I have more respect for a design that takes that trade and says so than for one that makes the same trade and calls itself open.

Where I think it fits: work where the order and timing of records has to be settled and stay settled, where costs have to be budgeted in advance, and where knowing who your counterparties are is a requirement of the job rather than an inconvenience. The consensus service maps onto that demand almost exactly, which is why I read it as what this network is actually selling rather than as one line in a feature list.

Where I think it does not fit: uses where permissionless participation and resistance to exclusion are the whole point. For those, this network is structurally not the answer, and I would not call that a defect. It is the consequence of having built something else, and a reader who puts that openness first will weigh the same facts differently.

What I am least comfortable with sits in the coin rather than in the technology. Fees in dollars, supply fixed at launch, rewards paid from an account rather than from issuance: put those three together and I cannot draw a clean line from network usage to demand for HBAR. I am not claiming the line does not exist. I am saying I cannot show it to you with a number, and anyone who finds it obvious should be able to point at the part of the fee model that produces it. If I am wrong about this, that is where I am wrong, and it is the part I would want checked hardest.

One place I think critics are behind the facts. The old line about closed, patented technology described a real situation, and it stopped describing this one when the intellectual property was acquired and the implementation was released under an open licence. A criticism aimed at the current structure, at a consensus set that runs on a published list of named operators, still holds. One aimed at the patent describes a network that has since changed.

14. Buying, moving and staking HBAR without guessing

The spot pairs named here and on the cards below were read from each exchange’s own public ticker listing, and a pair list is something an exchange adds to and removes from. OKX listed HBAR against USDT, USDC and USD, and Bitget against USDT. Beyond those we make no claim either way, and which products appear on your screen differs by region, so check what your own account actually shows before you move money. Our exchange comparison covers the wider selection question.

On moving coins, one detail causes most of the trouble. An account on this network is identified by a short number in the form 0.0.x, and an address format compatible with Ethereum tooling also exists for the same account. Copy the destination exactly as the receiving side displays it, and if a deposit screen shows a memo field alongside the address, treat that field as part of the address rather than as a note to yourself. Withdrawals that arrive without it are the most common way people end up reading our guides on sending to the wrong place and on deposits that never show up. Choosing where to keep the coins afterwards is the subject of our wallet guide, and if you leave them with the exchange and use its earn or staking product, the rate on that screen is the exchange’s own number rather than the network parameter described further up.

15. The terms used in this article, in plain words

Questions readers ask about Hedera and HBAR

Compare the exchanges that list HBAR →