Deep diveOur Hedera Hashgraph Practice
Hedera governance, consensus and fees, explained for a risk committee
Hedera governance rests on three things a risk committee can examine: a council of organizations with equal votes that approves network software and reviews pricing, a consensus algorithm with deterministic finality under a stated fault assumption, and an open codebase maintained under a neutral foundation. None of that removes risk. It changes which risks you record, and what evidence you attach to the paper.
On this page
- What a technology risk committee actually needs from this paper
- Terms to define in the committee paper
- Who shapes the network your application depends on
- Node operation today and the stated path to wider participation
- Committee questions, short answers and the evidence to attach
- Residual risks the committee should still record
- One-page committee paper, section by section
- Questions and answers
- Sources
What a technology risk committee actually needs from this paper
A risk committee is not asking whether distributed ledgers are interesting. It is asking whether the organization is taking on a dependency it understands: who can change the platform, how a recorded transaction could be undone, what it will cost, and what happens if the dependency fails or changes hands.
ColdAI's founder has described Hedera's appeal to regulated firms in exactly those terms: predictable fees, fast finality and a consensus model that can be defended in front of a risk committee6. A defensible paper does not stop at those claims. It explains each one in plain language, attaches the primary evidence, and states the risks that remain.
Terms to define in the committee paper
- Hedera Council
- The group of organizations that governs the Hedera network. Members have equal votes, serve limited terms and approve updates to the network's software1.
- aBFT
- Asynchronous Byzantine fault tolerance: the network reaches agreement even if some participants are faulty or dishonest and messages are delayed, provided more than two-thirds of nodes follow the protocol3.
- Virtual voting
- Nodes work out how every other node would vote from the shared history of who gossiped what to whom, so no vote messages are sent3.
- Fair timestamp
- A transaction's consensus time is the median of the times at which nodes first received it, so a few faulty clocks cannot move it far3.
- Finality
- Once consensus places a transaction in order, that position is certain and cannot be changed; there is no probabilistic waiting period3.
- Hiero
- The open-source project, hosted by the Linux Foundation Decentralized Trust, to which Hedera contributed its codebase5.
- Network exchange rate
- The rate the network uses to convert fees, defined in US dollars, into the HBAR actually charged to the payer4.
Who shapes the network your application depends on
- Hedera mainnet
The public network your transactions are ordered and recorded on.
- Hedera Council
Approves software upgrades and reviews pricing, with equal votes per member.
- Node operators
Currently Council members; the stated plan is to widen participation over time.
- Hiero codebase
Open-source code maintained under the Linux Foundation Decentralized Trust.
- Mirror node operators
Anyone may run one to store and serve history; they take no part in consensus.
- Your application
Pays fees, holds its own keys and decides what data goes on the network.
Node operation today and the stated path to wider participation
Committees often ask whether a council-run network is really decentralized. The honest answer has two parts. Today, Council members operate the network's consensus nodes, so participation is permissioned and limited to vetted organizations1. Hedera's documentation describes a plan to widen node hosting, first to other trusted organizations and eventually to anyone who meets hardware and bandwidth requirements, while warning that timeframes may change and nothing is guaranteed2.
For the paper, record the current state as fact and the roadmap as intent. The relevant control is not a forecast of when broader participation arrives; it is monitoring governance announcements and reviewing the dependency whenever the node model, the Council's composition or its decision rules change.
Committee questions, short answers and the evidence to attach
| Question | Short answer | Evidence to attach |
|---|---|---|
| Who can change the platform? | The Council approves network software updates; members vote equally | Council governance page and published minutes1 |
| Can a recorded transaction be reversed by the network? | No; consensus order is final under the stated fault assumption | Hashgraph consensus documentation3 |
| Will costs move with the token price? | Fees are defined in USD and converted to HBAR at the network rate | Fee model documentation and the current fee schedule4 |
| How is pricing changed? | The Council reviews pricing at its regular meetings | Governance FAQ2 |
| Can we inspect the code? | Yes; the codebase is open source under the Hiero project | Linux Foundation Decentralized Trust announcement5 |
| What do we control ourselves? | Our keys, our data placement and our application logic | Internal key-management policy and architecture design |
Keep answers this short in the paper itself; put detail in an annex that cites the primary sources directly.
Residual risks the committee should still record
Dependency on a network the organization does not control
Early signalUnplanned unavailability, or a maintenance window that overlaps a business deadline.
MitigationQueue transactions in your own systems so users are not blocked, monitor network status and document an operating mode for extended outages.
Changes in governance, pricing or the node model
Early signalCouncil announcements, fee schedule updates or roadmap changes.
MitigationAssign an owner to track governance news and trigger a dependency review when any of the three changes.
Loss or compromise of the organization's own keys
Early signalUnexpected signatures, or a key holder leaving without handover.
MitigationHSM or KMS custody, threshold keys for high-value powers and a tested key rotation procedure.
Holding HBAR to pay fees
Early signalFinance asks how fee balances are classified, valued or safeguarded.
MitigationKeep balances small and purpose-bound, agree treatment with finance and auditors, and document who can move them.
Regulatory treatment of the application itself
Early signalThe use case touches payments, securities, custody or personal data.
MitigationNetwork properties do not settle regulatory status; obtain legal analysis for the actual activity before launch.
One-page committee paper, section by section
Questions and answers
Does using Hedera mean our organization has to hold HBAR?
Yes, in small amounts. Transaction fees are defined in US dollars but charged in HBAR, so every account that pays fees needs an HBAR balance. Most organizations keep a modest, purpose-bound buffer in dedicated payer accounts, top it up from treasury, and agree its accounting treatment and controls with finance and auditors before go-live.
What happens to our application if the Hedera network is unavailable?
Transactions cannot reach consensus until the network is available again, but nothing already recorded is lost. Design the application so that business actions queue internally, users see a pending state, and transactions are rebuilt if their validity window expires. Document the outage mode in the operational runbook and include it in the committee's risk register.
What is the exit strategy if we later decide to leave Hedera?
Keep the authoritative business records, documents and keys in systems you control, and treat the network as an evidence and settlement layer. Then exit means exporting history from mirror nodes, re-issuing any tokens elsewhere and migrating holders. The more state that lives only on the network, the more work exit becomes, so decide this split at design time.
Sources
- Hedera Council — Hedera Council · checked 10 October 2026
- Governance FAQ — Hedera documentation · checked 10 October 2026
- Hashgraph consensus algorithm — Hedera documentation · checked 10 October 2026
- Fee model — Hedera documentation · checked 10 October 2026
- Hedera becomes founding Premier Member of Linux Foundation Decentralized Trust — Linux Foundation Decentralized Trust · checked 10 October 2026
- Our Hedera Hashgraph practice — ColdAI