Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
Hedera publicly describes itself as a public distributed ledger built on the hashgraph consensus algorithm, which it presents as fast, fair, secure, and efficient without proof-of-work.
(Source: Hedera Whitepaper, Hashgraph Consensus Algorithm)
(b) Operational priorities
The cited materials show that ongoing operations rely on Council-governed treasury management, Council-operated consensus nodes, staking rewards, and ecosystem and open-source development support through Hedera Foundation and Project Hiero.
(Source: Treasury Management, Staking Program, Who We Are, Hiero Turns One, Introducing Hiero)
(c) High-level project overview
At a high level, Hedera says nodes gossip transaction information, use virtual voting for consensus, and assign fair timestamps and ordering to transactions. The network account model uses HBAR as the native asset held by accounts and charged for transactions and queries.
(Source: Hashgraph Consensus Algorithm, Accounts, Hedera Council FAQs, Hiero Turns One)
(d) Primary token functions
The cited materials show that HBAR's primary public functions are paying transaction and query fees, serving as the native asset held by accounts, and contributing to staking-based consensus weight and rewards.
(Source: Accounts, Staking Program, Hedera Council FAQs)
(e) Control surface reliance
The cited materials show that the control surface relies on Hedera Council governance rather than tokenholder-wide onchain voting. Council members participate in governance, operate nodes, cryptographically sign transactions, and can change total supply only by unanimous consent.
(Source: Hedera Council FAQs, Treasury Management, Introducing Hiero)
Known Project Team
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Full Name | Entity | Official Title | Prior Experience |
|---|---|---|---|
Eric Piscini | Labs | Chief Executive Officer of Hashgraph | Hashgraph says Eric Piscini previously held executive and management roles at IBM Watson Health, Emerging Business Networks, Deloitte, and Citizens Reserve. |
Dr. Leemon Baird | Foundation | Co-founder and Chief Scientist at Hashgraph. | Hashgraph says Dr. Leemon Baird invented the distributed hashgraph consensus algorithm, co-founded Hedera with Mance Harmon, served as Professor of Computer Science at the U.S. Air Force Academy, and earned a PhD in Computer Science from Carnegie Mellon University. |
Mance Harmon | Foundation | Co-founder of Hedera and Chairman of the Board at Hashgraph. | Hashgraph says Mance Harmon previously led startups, served as Head of Architecture and Labs at Ping Identity, managed product security, and taught cybersecurity at the U.S. Air Force Academy. |
Tom Sylvester | DAO | President of Hedera Council | Hedera states that Tom Sylvester joined Hedera's legal team in 2018 and helped shape the legal, governance, and strategic frameworks used in Council governance. |
Mance Harmon | DAO | Chairman of Hedera Council and Chairman of Hashgraph | The cited materials identify Mance Harmon as a co-founder of Hedera and one of the founders of the Swirlds entity that formed the initial Council member. |
Blockworks note: The cited materials do not identify a DAO executive structure. The closest public governance-leadership surface is Hedera Council. |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List onchain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., onchain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
The cited materials do not describe Hedera as having a DAO or DAO-controlled legal wrapper. No public data found in cited sources regarding DAO-specific IP ownership or control.
(Source: Treasury Management, Hiero at LF Decentralized Trust)
(b) Contract/admin powers
The public governance surface is Hedera Council, a Delaware LLC formed to act as the governing body for the Hedera Network. Public sources say each Council member has one vote on matters submitted for member votes, the Board oversees management and operations, and Council members participate in governance, operate nodes, and cryptographically sign transactions. The public LLC Agreement also says at least 80% of members may approve required capital contributions for extraordinary expenses or similar liabilities.
(Source: LLC Agreement, Hedera Council FAQs, Treasury Management)
(c) Locked-token rights (conditional)
HBAR staking can increase a node's consensus weight and generate rewards, but the staking program says there is no lock-up period, no bonding, and no slashing. The cited materials in this run do not identify token-locking-based governance rights for HBAR holders.
(Source: Staking Program, Hedera Council FAQs)
(d) Value accrual & holder rights
No DAO exists in the public record. The public Council LLC Agreement says the Council makes no distributions other than in conjunction with final liquidation, but cited materials do not identify DAO-level revenue distribution or treasury-rights for tokenholders.
(Source: LLC Agreement, Hedera Council FAQs)
(e) Dissolution authority
No public DAO dissolution mechanism was identified in cited sources because the reviewed governance model is Hedera Council rather than a DAO.
(Source: LLC Agreement, Hedera Council FAQs)
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The public record identifies Hedera Foundation as an independent entity, rebranded from The HBAR Foundation, and publicly identifies the website operator as Hedera Foundation SEZC. Hedera Foundation publicly describes itself as focused on community-driven retail innovation, institutional adoption, funding opportunities, tokenization, AI, DeFi, and builder support on the Hedera network. No public data found in cited sources for the nonpublic items requested in section 4(a)-(f), including detailed jurisdiction, IP/control rights, powers over treasury or DevCo, admin authorities, or current distribution policies beyond the public ecosystem-support mission.
(b) IP ownership & control
N/A
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
N/A
(d) Powers over DevCo
N/A
(e) Contract/admin powers
N/A
(f) Current economic arrangements and distribution policies
N/A
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
The cited materials now identify Hashgraph, formerly Swirlds Labs, as the clearest current DevCo-like operating company in the Hedera ecosystem. Hashgraph says it employs more than 140 professionals across 20 countries and leads product innovation, technical development, and marketing initiatives geared at growing the Hedera ecosystem. The cited materials also say Hedera contributed the entirety of its source code to LF Decentralized Trust as Project Hiero, while operational governance of the network remains with Hedera Council. Current treasury reporting says Network Governance and Operations includes HBAR used as compensation to founders, executives, employees, and contractors, but cited materials still do not provide the nonpublic power and economic details requested in section 5(a)-(f), including detailed powers over the treasury, Foundation, protocol-controlled resources, or token administration.
(Source: Hashgraph About, Hello Hashgraph, Hedera Council FAQs, Treasury Management, Hiero at LF Decentralized Trust,)
(b) IP ownership & control
N/A
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
N/A
(d) Powers over Foundation
N/A
(e) Contract/admin powers
N/A
(f) Current economic arrangements and distribution policies
N/A
Token Supply & Allocations
Initial Allocation
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.
- (a) Launch supply totals — The total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch.
- (b) Recipient categories & use of funds — The recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket.
- (c) Initial price per token (if applicable) — The initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
- (d) Ticker / market symbol — The ticker/market symbol.
- (e) Total supply & supply regime — The total supply and whether the supply is fixed (if not explain inflation rate or deflation rate).
- (f) Initial vesting / release schedules — The initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).
(a) Launch supply totals
Current public sources say Hedera launched in August 2018 with a fixed total supply of 50 billion HBAR minted into Treasury accounts. Hedera's economics paper says that before open access almost all HBAR remained in Treasury except 6.7 million HBAR distributed to early users for community testing. The public record still does not provide a precise locked-versus-unlocked split for the August 2018 launch date itself. For public SAFT release detail, the later Series 1 schedule released 2% on the date of Open Access, 2% in the following seven days, and the remainder through September 2023; the later Series 2 schedule released 5% on the date of Open Access, 5% in the following seven days, and the remainder through September 2022.
(b) Recipient categories & use of funds
Launch-era public distribution guidance said the expected initial token distribution was approximately 65% Hedera Council Treasury, 17% Hedera management and employees, 13% SAFT purchasers and developers, and 5% Swirlds. Hedera's economics paper adds that, when public access opened on September 16, 2019, approximately 46% of the 50 billion HBAR had been allocated and 54% remained in Treasury. Current treasury reporting groups supply into Initial Development Costs and Licensing (7.77%), Purchase Agreements (25.40%), Network Governance and Operations (16.23%), and Ecosystem and Open Source Development (50.61%). (Source: Hedera accredited crowdsale FAQ, HBAR Economics, Treasury Management)
(c) Initial price per token (if applicable)
The cited materials identify SAFT prices of $0.12 per token and $0.096 per token under two accredited-crowdsale release options, but the public record for this run does not identify a single fixed public TGE price at open access. (Source: Hedera accredited crowdsale FAQ)
(d) Ticker / market symbol
The ticker / market symbol is HBAR. (Source: Accounts, CoinGecko HBAR)
(e) Total supply & supply regime
Public treasury reporting says HBAR has a fixed total supply of 50 billion and that any supply change would require unanimous consent of the Hedera Council. (Source: Treasury Management, Staking Program)
(f) Initial vesting / release schedules
Public launch materials describe staged release schedules rather than immediate full unlocks: crowdsale Option A released 20% six months after network launch and 10% monthly over the next eight months, while Option B released 20% six months after network launch and 20% yearly over the next four years. The HBAR economics paper says SAFT 3A distributed monthly over 9 months, SAFT 2 monthly over 3 years, SAFT 1 quarterly over 4 years, and SAFT 3B annually over 4 years. The same paper says Dr. Baird and Mr. Harmon each had a 2 billion HBAR coin grant vesting over six years, and that restricted coin unit grants to employees and contractors typically followed a four-year vesting schedule with a one-year cliff and monthly vesting thereafter. (Source: Hedera accredited crowdsale FAQ, HBAR Economics, Hedera Council FAQs)
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
-
Planned but not yet executed airdrop: This sub-item does not apply. Hedera has no planned or pending TGE airdrop. The 50 billion HBAR total supply was fully minted at network launch on August 24, 2018, and distribution occurs through Council-governed treasury releases rather than an airdrop.
(Source: Treasury Management, Hedera accredited crowdsale FAQ)
-
Executed airdrop: This sub-item does not apply. Hedera has never executed an airdrop, and no per-address airdrop dataset exists because no airdrop occurred.
(Source: Hedera accredited crowdsale FAQ)
-
No airdrop planned or conducted: Hedera has never conducted an airdrop to date and does not plan to execute one. Hedera's 2018 crowdsale FAQ stated the project did not expect to have an airdrop and instead contemplated testing programs where community members could earn tokens for testing the network or participating in hackathons, regulations permitting.
(Source: Hedera accredited crowdsale FAQ)
Blockworks note: Hedera executed the earn-through-testing approach by releasing 6.7 million HBAR to early users through its community testing program before Open Access on September 16, 2019. These distributions were earned incentive payments for network testing, not an airdrop, and are classified under the Community Incentive Program within the Ecosystem and Open Source Development allocation category in the Council treasury report.
(Source: Hedera Council FAQs, Treasury Management)
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:
- (a) Market maker's name — the market maker's name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes.
If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Blockworks note: Hedera has not publicly disclosed any market maker agreements, token allocations to market makers, or token loans to market makers. The Council treasury report does not include a market maker allocation category.
(Source: Treasury Management)
CEX / DEX Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
- (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
- (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
- (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
- (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.
If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Blockworks note: Hedera has not publicly disclosed any CEX or DEX listing agreements, token allocations committed for listings, or listing fees paid in HBAR. The Council treasury report does not include an exchange listing allocation category.
(Source: Treasury Management)
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
- (a) Series Name
- (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
- (c) Date of sale (at least month & year)
- (d) Number of tokens sold (or % of total supply)
- (e) Vesting schedule
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
- Series Name: Series 1
- Investment Vehicle: SAFT
- Date Of Sale: 2017-12 to 2018-01
- Number of tokens sold: 4.9 billion split-adjusted HBAR, or 9.8% of total supply
- Vesting Schedule: Amended to release 2% at Open Access, 2% in the following seven days, and the remainder through 2023-09
- Series Name: Series 2
- Investment Vehicle: SAFT
- Date Of Sale: 2018-01 to 2018-03
- Number of tokens sold: 2.9 billion split-adjusted HBAR, or 5.8% of total supply
- Vesting Schedule: Amended to release 5% at Open Access, 5% in the following seven days, and the remainder through 2022-09
- Series Name: Series 3 / Accredited Crowdsale
- Investment Vehicle: SAFT
- Date Of Sale: 2018-04 to 2018-08
- Number of tokens sold: 922 million HBAR, or 1.9% of total supply
- Vesting Schedule: SAFT 3A distributed monthly over 9 months and SAFT 3B distributed annually over 4 years. The public record does not allocate token counts between the two tranches
- Series Name: Coin Purchase Agreements
- Investment Vehicle: Token Purchase Agreements
- Date Of Sale: 2020
- Number of tokens sold: 1,333,333,333 HBAR, or 2.67% of total supply
- Vesting Schedule: Purchasers received no HBAR for the first two years after sale, followed by delivery in 12 equal monthly installments
Blockworks note: (Source: Hedera Council FAQs, HBAR Economics, Treasury Management)
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References (optional) — References (optional): link(s) to post-mortem/advisory/PR.
(a) Date & component affected
On March 9, 2023, an attacker exploited Hedera mainnet Smart Contract Service code and targeted HTS tokens held by certain DEX liquidity-pool accounts.
(Source: Precompile Attack Postmortem)
(b) Exploit vector summary
Hedera said the attacker exploited a bug in precompiled-contract behavior so a smart contract using delegatecall could gain unauthorized withdrawal rights over targeted DEX pools.
(Source: Precompile Attack Postmortem)
(c) Quantified impact
Hedera said the assets stolen before containment were valued at just under $600,000 and included 1,001 DAI, 66,997 USDT, 287,998 USDC, and 3,630,000 WHBAR across multiple accounts and DEXs.
(Source: Precompile Attack Postmortem)
(d) Remediation/response taken
Hedera said DEXs and bridges worked to stop bridge flows, Hedera DevOps shut off proxy access to mainnet at 20:18 UTC on March 9, 2023, maintainers developed and tested a fix within 13 hours, and Council node operators signed transactions to update the network code.
(Source: Precompile Attack Postmortem)
(e) Current status
Hedera said the mainnet upgrade completed at 02:04 UTC on March 11, 2023 and permanently prevented a smart contract from using delegatecall to invoke the HTS precompile.
(Source: Precompile Attack Postmortem)
(f) References (optional)
Official postmortem is at Analysis & Remediation of the Precompile Attack on the Hedera Network.
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
-
(a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
-
Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
-
Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
-
Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
-
Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
-
(b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
-
Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
-
Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
-
(c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
-
Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
-
Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
Impact of Regulatory Change on TGE and Listings
Hedera's own launch-era fundraising materials show that SAFT sales were limited to accredited investors and withheld from jurisdictions where legal counsel believed local law could create offering or token-sale risk. That public history suggests future regulatory divergence could affect token delivery, fundraising structure, and listing or maintenance in particular jurisdictions.
(Source: Hedera accredited crowdsale FAQ, Treasury Management)
Entity-Level Regulatory Impact
The cited materials show a multi-entity structure that includes Hedera Council, Hedera Foundation, and ecosystem contributors such as Hashgraph. Changes in securities, commodities, sanctions, privacy, or local operating rules could force changes to grant programs, market access, or how these entities interact with users and builders.
(Source: Hedera Council FAQs, Hedera Foundation Terms, A New Era For Hedera, Terms)
Tokenholder Tax Treatment
The cited materials in this run did not identify project-authored tokenholder tax guidance, and the public terms frame HBAR use as subject to applicable law rather than offering user-specific tax guidance. That leaves tokenholders to assess their own tax obligations without project-specific public instructions in the reviewed source set.
(Source: Terms)
Jurisdictional and User Access Restrictions
Public fundraising materials said the SAFT was offered in 63 countries and not offered where legal counsel saw elevated legal risk, and Hedera's terms reserve access restrictions tied to law, sanctions, and security. Those restrictions can limit user access and create jurisdiction-specific onboarding and listing risk.
(Source: Hedera accredited crowdsale FAQ, Terms)
(b) Protocol, Technology & Security Risks
Bugs and Design Flaws
The March 2023 precompile attack shows that implementation flaws in the Smart Contract Service / HTS integration could let an attacker obtain unauthorized withdrawal rights over DEX liquidity pools and drain bridged or DEX-held assets. Hedera said the stolen tokens were valued at just under $600,000 before containment.
(Source: Precompile Attack Postmortem)
Security Measures & Their Limitations
The cited materials show Hedera runs a bug bounty program, publishes audit and standards materials, and open-sourced the codebase through Hiero, but the precompile incident itself shows that bug bounties, audits, and open-source review do not prevent every design or implementation flaw from reaching production.
(Source: Bug Bounty Program, Audits and Standards, Introducing Hiero, Precompile Attack Postmortem)
(c) Token Economics, Unlocks & Incentive Risks
Critical Economic Assumptions
HBAR utility and network incentives rely on continued demand for transaction processing, fee collection, and staking participation. Public staking and treasury materials show rewards are funded through network fee flows and council-managed allocations, so weaker usage or misaligned incentives could reduce reward attractiveness and slow ecosystem growth.
(Source: Staking Program, Treasury Management)
Governance Control over Monetary Policy & Rewards
Public sources show the total supply is fixed at 50 billion HBAR unless the Hedera Council unanimously consents to change it, and council governance surfaces say the Coin Economics & Treasury Management Committee advises on treasury, pricing, and economic incentive structures including staking and node operations. That means governance decisions can materially affect treasury deployment, pricing, and reward mechanics even if total supply remains fixed.
(Source: Treasury Management, About Governance, Hedera Council FAQs)
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.