Index

HBAR was not offered through a traditional public offering nor an Initial Coin Offering (ICO). Instead, it is available for trading on numerous wallets and crypto asset exchanges globally. This method allows users to purchase HBAR directly from the open market.The totality of hbars were initially minted in 2017. A very small amount of coins (6.7 million HBAR) was released in the following months to early users to test the network as part of its community testing program. Since, hbars have been acquired by buyers by regulated investment contracts: Simple Agreements for Future Tokens (SAFTs) under applicable securities laws (US Securities Act of 1933), specifically Regulation D. The initial SAFT purchasers were presented with an option to acquire additional hbars in exchange for agreeing to a prolonged, pre-determined schedule for token release. After the Hedera network became operational, Token Purchase Agreements (TPAs), which are classified as physical forward agreements under applicable law, were entered to sell hbars to eligible contract participants (ECPs). Physical forward agreements are excluded from the definition of swap agreements under relevant commodity laws, but were nevertheless reported to the applicable US regulator for the purpose of full transparency. The TPAs were offered to support the ongoing operations of the network. The multiple SAFT series included an initial sale to early users as part of a community testing programme, and later Open Access for the general public. Details of the SAFT offerings follow:

Note that, as part of the terms of the original licence agreement, the Hedera Council distributed 2.5 billion coins (5%) to Swirlds, Inc. Independent of the licence agreement, an additional 1 billion coins are allocated to Swirlds investors (excluding the Hedera Council founders). At the time of submission of this whitepaper, there is still an unallocated supply of 67,018,958 hbars (0.13%), which could be distributed to network operations or ecosystem development. Following its initial distribution, HBAR became available on multiple trading platforms, including major exchanges like Binance, Coinbase, Huobi, and OKEx, where it is traded against various fiat and cryptocurrency pairs.Proceeds from HBAR sales were and are used to fund the development of the network, including open-source and ecosystem development (e.g. grant programmes), and compensation to founders, executives, employees and contractors in accordance to compensation schedules. Until 2022, when all intellectual property was purchased and acquired by the Hedera Council, this also included monthly compensation to Swirlds, Inc. as part of the Hashgraph License Agreement.

• Development and operation of software platforms that support distributed consensus computing, including PlatformasaService (PaaS) offerings built on distributed ledger technology for cryptographically securing and processing data related to cryptoasset transactions.
• Providing a website featuring information about distributed ledger computing; software as a service (SAAS) services featuring software for distributed ledger technology, cryptocurrency, virtual currency, and digital tokens, namely, software for authenticating, facilitating, and processing data; platform as a service featuring computer software platforms for distributed ledger technology and authenticating, facilitating and processing data in the fields of cryptocurrency, virtual currency, and digital tokens; providing information in the field of computer software and distributed ledger technology.

• 2012 to 2015: Leemon Baird’s ground research towards the invention of the hashgraph.
• 2015 to 2016: Baird partners with Mance Harmon (Swirlds) to develop proofs of concept and commercialise hashgraph.
• 31 May 2016: Hashgraph whitepaper is published.
• Q1 to Q2 2017: Seed investment round by Swirlds.
• Q3 to Q4 2017: Founding team, business development team, legal` team and recruitment team are brought onboard. “Hashgraph Consortium, LLC” is created as a Delaware company. Hashgraph technology is displayed publicly for the first time at TechCrunch Disrupt in San Francisco (California).
• Q1 2018: First formal meeting of the executive team. Hedera is selected as the brand and company name. HBAR logo is designed. First Letters of Intent by potential Council Members. Launch event is held. HederaHashgraph.com goes live.
• Q2 2018: Company name is formally changed to Hedera Hashgraph,LLC. The multimember LLC Agreement (document governing the Hedera Council) is drafted.
• Q3 2018: Hedera network MainNet goes live and 50 billion HBAR are minted.Q4 2018: First Hedera network developer conference and global hackathon. COQ proof by Carnegie Mellon academic confirms hashgraph’s asynchronous byzantine fault tolerance.
• Q1 2019: First Hedera Council members (Deutsche Telekom, DLA Piper, Magazine Luiza, Nomura Holdings, Inc., and Swisscom Blockchain)are announced, and the first Council meeting takes place.
• Q2 2019: Phase two of the Community Testing Programme begins.
• Q3 2019: Hedera network’s Mirror Node software enters alpha.Hedera mainnet (beta) is made openly accessible.
• Q4 2019: The Hedera Boost programme to support startups building on the Hedera network is launched.
• Q1 2020: Hedera Consensus Service (HCS) is launched on MainNet.Hedera.com goes live.
• Q2 2020: Hedera network surpasses Ethereum in the daily number of transactions processed.
• Q3 2020: Hedera network's Mirror Node software enters beta.Hedera previewnet goes live. All of the Hedera network services, including HCS, enter open source under Apache 2.0 licence on August 6, 2020.Hedera's State Proof software enters alpha.
• Q4 2020: The code for the hashgraph platform enters open review. Hedera Token Service (HTS) is launched on the previewnet and the Tokenization on Hedera whitepaper is published.
• Q1 2021: HTS is launched on the MainNet.
• Q2 2021: Hedera network reaches one billion (1,000,000,000) MainNet transactions in just one year, six months, and 28 days. The Hedera Public Mirror Node becomes available.
• Q3 2021: Hedera Council adopts environmental sustainability as a core value and officially commits to a carbonnegative network. The Hedera Council allocates 10.7 billion hbars (at the time, approximately $5,000,000,000) to the newly established independent grantgiving organisation, the HBAR Foundation.
• Q1 2022: The Hedera Council votes to purchase and open source the intellectual property rights to the hashgraph consensus algorithm. Hedera Smart Contract Service (HSCS) 2.0 is launched on the TestNet and then on the MainNet.
• Q2 2022: The Hedera Council further decentralises the Hedera network with the transition of the Development and Management teams, including Dr. Leemon Baird and Mance Harmon, from the Hedera Council to Hashgraph Foundry (f/k/a Swirlds Labs).Last IP payment to Swirlds.
• Q3 2022: The hashgraph platform, including the hashgraph consensus algorithm, enters open source under Apache 2.0 licence, making the entire Hedera network, including the services code and developer tools, open source. Native staking is introduced on the Hedera network.
• Q4 2022: EVM archive node functionality enabled to query the state of smart contracts on Hedera.
• Q1 2023: Mainnet upgrade with a code change preventing smart contracts from using a delegate call to call a precompiled contract. Mutable metadata fields for fungible and nonfungible tokens are enabled. The Hedera Council approves a formal Council Development Policy to guide recruitment of new members.
• Q2 2023: The Hedera Council approved the allocation of 3.735 billion hbars to fulfill contractual obligations including SAFT redemptions and operational costs and to support ongoing ecosystem development.
• Q3 2023: Security enhancements of the Hedera smart contract service (HSCS), introduction of changes in the staking algorithm including a 2.5% maximum reward, launch of the Stablecoin Studio, reduction of NFT minting fees and implementation of bulk minting pricing to optimize largescale issuance.
• Q4 2023: Separation of the roles of Hedera Council Chair and President, release of HSCS Security Model v2, and release of onchain smart contract verification.
• Q1 2024: Launch of a new anonymous testnet faucet, revamp of Hedera Portal UI for improved developer onboarding, and allocation of 4.86 billion hbars to ecosystem enablers The HBAR Foundation, Hashgraph Association and DLT Science Foundation as part of ecosystem decentralization and growth efforts.
• Q2 2024: Introduction of support for dynamic NFTs and advanced token metadata; Hedera joinder of the Crypto Information Sharing and Analysis Center (Crypto ISAC).
• Q3 2024: Launch of the Asset Tokenization Studio, founding of the DeRec (Decentralized Recovery) Alliance, founding of the Linux Foundation Decentralized Trust, and donation of the entirety of the Hedera source code to it (“Hiero” project).
• Q4 2024: Founding of the MiCA Crypto Alliance and upgrade of the Hederaoperated Mirror Node.
• Q1 2025: Release of the Standards SDK opensource toolkit consolidating multiple Hashgraph Consensus Standards into a unified framework, including an AI Agent Communication Protocol and recursion within the Hedera Consensus Service.

• Reaching 39 organisations in the Hedera Council.
• Enabling community mirror nodes. Enter "phase 4" of Hedera Governance where the faculties of the Council and the management team are further reduced.
• Enabling weighted staking.
• Enabling community consensus nodes.
• Depermissioning of the network, allowing anyone to run a Hedera network validator node.

• Initial Development Costs and Licensing: 3,869,316,000 hbars (7.74%) have been allocated for the initial development and licensing of the hashgraph technology, including payments to Swirlds, Inc. for ongoing use and the acquisition of intellectual property rights.
• Purchase Agreements: 12,698,348,449 hbars (25.40%) are used for regulated sales contracts such as Simple Agreements for Future Tokens (SAFTs) and Token Purchase Agreements (TPAs) to support network functionality and operations.
• Network Governance and Operations: 8,116,201,648 hbars (16.23%) cover compensation for founders, executives, and contributors, adapting to the evolving governance and operational needs of the network.
• Ecosystem and Open Source Development: 25,249,114,945 hbars (50.50%) are dedicated to fostering the ecosystem's growth through community incentives, developer grants, and significant initiatives led by the Hedera Council to decentralise and enhance network activities.
  1. The remaining 67,018,958 hbars (0.13% of the total supply) are unallocated, reserved for future strategic uses as determined necessary by the Hedera Council at its discretion. The Hedera Council may allocate these funds to:
• Support the LLC’s operational continuity (through compensation structures and expenses).
• Fund independent ecosystem development organisations such as The HBAR Foundation, The Hashgraph Association and Exponential Science.
  1. These planned allocations are subject to adjustment based on strategic reviews and may vary with the actual and forecasted value of hbars. A part of the existing supply has also not yet been released, but has been allocated as per section D.9. These hbars will be used to afford contractual commitments such as those established in SAFTs and TPAs.

• Promoting Public Awareness of DLT: Increasing understanding of DLT’s benefits and applications through campaigns, webinars, and collaborations.
• Educational Services: Offering training in DLT and blockchain technologies to equip individuals with the skills needed for implementation and development.

• CNSA standards in Hedera TLS (Transport Layer Security) protocol connections between nodes and as as part of cryptographic operations for onchain operations:
  • 384-bit SHA-2 hashes (considered “quantum resistant” per CNSA 2.0 Quantum Computing Guidance 2024) in Hash-based Message Authentication Code (HMAC).
  • 256-bit AES keys for symmetric encryption.
  • RSA with 2048-bit keys.
• Ed25519 signature algorithm for publicprivate key pairs.
• ECDSA (secp256k1) key type signature algorithm for publicprivate key pairs.
• Support for simple keys, key lists, and threshold keys.
  1. Hedera was designed to allow for changes to meet new demand and evolving standards. For example, the anticipated challenges posed by quantum computing would require fundamental changes in most DLTs, but Hedera is able to introduce new cryptographic algorithms without undertaking a hard fork, has demonstrated this capability by including ECDSA_SECP256K1 support after the network launched, and will be able to similarly introduce post-quantum algorithms.
  1. In addition, the Hedera Smart Contract Service runs an Ethereum Virtual Machine (EVM) environment, supporting token standards ERC-20 and ERC-721.
  1. Furthermore, the Hedera network supports interface standards:
• gRPC and gRPC variants like gRPCWeb: for interaction with the Hedera Consensus Service (HCS) and Hedera Smart Contract Service.
• PKCS #11 (Cryptographic Token Interface Standard), enabling secure key operations via hardware security modules in TLS configurations.
• REST: RESTful endpoints define HTTPbased APIs for querying indexed ledger data (historical data) via mirror nodes.
• Protobuf: Protocol Buffers define serialisation format for structured data exchanged with the network (for transaction construction and signing).
  1. Finally, the Hedera network also supports developer standards, in the form of official SDKs (Software Development Kits) in Java, JavaScript/ Typescrit and Go. These SDKs have been open-sourced in the Hiero SDK.

• Gossip Protocol: The foundational communication mechanism in hashgraph is the gossip protocol. Each node in the network randomly communicates with another node and shares the latest information it knows. This process ensures that information spreads rapidly and efficiently across the network.
• Gossip about Gossip: To add another layer to this, the Hedera network does not just gossip transactions but about events which include information about previous events. This means each node not only shares its and the latest transactions but also includes additional information about how it learned those transactions. This metainformation constructs a graph of the transaction history, which is crucial for the consensus process.
• Virtual Voting: Unlike traditional DLTs which send voting messages via messagepassing, hashgraph uses virtual voting to achieve consensus. Due to the history of how transactions are gossiped.
• Event Nodes and Consensus Timestamps: In hashgraph, events are transactions or groups of transactions, which include timestamps. When a node creates an event, it tags the event with two hashes: the hash of the last event it created (parent hash) and the hash of the last event it received from another node (other hash). These linked events form a directed acyclic graph (DAG) of events known as the hashgraph. Through these hashes, each node keeps track of the 'see' and 'strongly see' relations which help in determining the famous witness events that decide consensus. A consensus timestamp is then assigned to each event, which is the median of the times when the event was first received by the nodes, ensuring a fair ordering based on when transactions were seen, not just when they were reported.
• Efficiency, Fairness and Finality: Hashgraph’s approach allows for consensus without the extensive computational and energy costs associated with proofofwork systems. The rapid propagation of information ensures that consensus is reached quickly and efficiently, while the virtual voting and event structuring maintain the integrity and fairness of the transaction order. Once an event reaches consensus, it is assigned a consensus timestamp which ensures deterministic finality. For a more indepth description of the features of the consensus mechanism, see section H.4.
  1. To maintain the ledger, the Hedera network uses types of nodes:
  1. 1. Consensus Nodes: These nodes are responsible for processing transactions, maintaining the state of the network, and ensuring transaction ordering. They play a critical role in the consensus mechanism of the Hedera network, verifying the order and validity of transactions. As of now, these nodes are operated under permission from the Hedera Council, which comprises various highly diversified organisations. The current strategy moves towards a model that incorporates non-Council operated nodes in a staged manner.
  1. 2. Mirror Nodes: Unlike Consensus Nodes, Mirror Nodes do not participate in the consensus process because they cannot create events. Instead, they play a vital role in providing access to the history of transactions without bearing the burden of processing transactions. They enable enhanced query capabilities by storing the history of transactions, making them essential for applications that need to fetch historical data. For developers and businesses looking to integrate with the Hedera network or utilise its data, mirror nodes offer a streamlined way to access historical data through REST APIs, reducing the complexity and resource requirements of running a full node.

• Cryptocurrency Service: Creating a cryptocurrency is charged at$0.05, whereas automatic renewal of a crypto account incurs a charge of $0.00022. Both deleting and approving allowances are billed at $0.05 each. Updating cryptocurrency details costs$0.00022, and a standard crypto transfer is $0.0001. Custom fees for crypto transfers are set at $0.002, and deleting a cryptocurrency account costs $0.005. Retrieving account records or balances and acquiring information or stakers all cost $0.0001 each, with the exception of getting the account balance, which is free.
• Consensus Service: Creating a topic costs $0.01, updating a topic is $0.00022, and deleting a topic is priced at $0.005. Submitting a message to a topic or retrieving topic information costs $0.0001.
• Token Service: Creating a token costs $1.00, but with custom fees, the cost is $2.00. Updating a token, updating the fee schedule, deleting a token, minting fungible tokens, burning tokens, granting or revoking KYC, freezing or unfreezing tokens, pausing or unpausing tokens, wiping tokens, and updating NFTs are all $0.001 each.Associating or dissociating tokens costs $0.05. Minting nonfungible tokens is $0.02, and bulk minting 10,000 NFTs is priced at $200. Retrieving various tokenrelated information costs $0.0001. If updating multiple NFTs in a single call, the charge is $0.001 per NFT.
• Schedule Transaction: Creating a schedule costs $0.01, signing a schedule is $0.001, and deleting a schedule is also $0.001.Retrieving schedule information is $0.0001.
• File Service: This service charges $0.05 for creating, updating, or appending to files, and $0.007 for deleting a file. Retrieving file contents or information costs $0.0001.
• Smart Contract Service: creating a contract is $1.00, updating a contract is $0.026, and deleting a contract costs $0.007. Making a contract call costs $0.05, local calls are $0.001, and retrieving bytecode or contractrelated information costs $0.05 and $0.0001 respectively. Automatic renewal for contracts is $0.026.
• Miscellaneous: Executing an Ethereum transaction, a PRNG transaction, and retrieving version information are priced at $0.0001,$0.001, and $0.001 respectively. Accessing data by key and receiving transaction receipts or records are free, except for transaction records, which cost $0.0001. (all values in US Dollars)The variable components means that actually charged fees might display discrepancies with the description above. These components account for the transaction complexity derived from the varying amount of resources that can be consumed fromone transaction to another. An updated fee structure can be found at https://hedera.com/fees and https:/docs.hedera.com/hedera/networks/mainnet/fees#transactionandqueryfees.

1. Cryptocurrency Service: This service allows for the creation, management, and transfer of cryptocurrencies within the Hedera network. It includes functionalities like creating accounts, transferring tokens between accounts, managing account properties through updates, and removing permissions through deletions. Advanced features include automatic renewals of crypto accounts and allowance management for decentralised approval mechanisms.
2. Consensus Service (HCS): Designed for applications requiring a secure, verifiable logging and messaging service, this allows users to create, manage, and delete topics that can be used for posting messages. Messages within these topics achieve consensus across the network, ensuring that they are recorded in a timely, immutable manner, providing traceability and reliability in communication.
3. Token Service (HTS): This service facilitates the creation and management of fungible and non-fungible tokens (NFTs) on the Hedera network. It supports operations such as token creation, association or dissociation with accounts, token minting and burning, and setting up KYC/AML compliance checks. It enables the tokenization of assets with robust management tools for broad application across various sectors.
4. File Service (HFS): It enables the storage, modification, and retrieval of files within the Hedera network. This service is key for applications that need decentralised, secure, and verifiable file storage solutions. It supports operations like file creation, updating, appending, and deletion, alongside capabilities to fetch file contents or metadata.
5. Smart Contract Service (HSCS): Utilising the Solidity programming language, this service allows the deployment and execution of smart contracts on the Hedera network. It supports contract creation, updates, deletions, and various types of contract calls. This service leverages the Hedera network's fast, fair, and secure properties to provide a powerful environment for running decentralised applications.
6. The Hedera network also offers secondary functionalities:
7. Scheduling Service: This feature allows users to schedule transactions to be executed at a future time or under specific conditions, facilitating delayed or conditional transactions. It supports creating, signing, and deleting scheduled transactions, making it ideal for automation and coordination of agreements and commitments in a decentralised environment.
8. Network Service: It handles operations that pertain to the broader network or its nodes rather than to user-controlled entities. This service is crucial for managing and overseeing the overall health and functionality of the network, ensuring that operations are scoped at a level that affects the entire system or significant parts of it.
9. Freeze Service: It is used by privileged accounts to temporarily halt network operations during scheduled maintenance windows. This service is essential for performing updates or modifications to the network without disrupting the integrity or performance of ongoing processes. It ensures that these actions are controlled and reversible, providing a safeguard during critical maintenance activities.
10. Util Service: This service encompasses utility operations on the network, which include a variety of tasks that support the network’s operational efficiency but do not fit neatly into the primary service categories. These operations might involve cleanup, diagnostics, or other maintenance-related activities that help in optimising the network performance and security.
11. Other functionalities involve:
12. Mirror Nodes: The Hedera network enables (and the Hedera Council also runs) nodes that provide access to historical data without burdening the main network, allowing developers to access transaction records and other historical data efficiently (see section H.1).
13. Miscellaneous Functionalities: The Hedera network offers a range of services like Ethereum transaction compatibility, pseudo-random number generation, and system version management. These services provide additional tools and functionalities needed by developers for application development and management on the Hedera network.

• Treasury Risks: While the Hedera Council counts on a Treasury to support its activities, and the Hedera network's nodes generate revenue through transaction fees and services, this treasury is not unlimited. In this context, insufficient network usage may pose a risk to the ability to support core operations related to node running and technical work.
• Internal Efficiency and Control Risks:
  • Resource Allocation Efficiency: The Hedera Council's financial health depends significantly on its ability to allocate resources efficiently across its technology development and market expansion. Mismanagement could lead to financial strain or inability to sustain long-term development.
  • Operational Integrity: Effective internal controls are crucial to manage and mitigate risks related to fraud, operational errors, and maintaining the integrity of the network. Weaknesses in these controls could undermine stakeholder confidence and operational efficiency.
  • Governance Practices: Robust governance is vital to maintaining investor and user trust, and Hedera's governance model is what attracts regulated enterprises to build on this network due to safe and trustworthiness attributes. At the same time, increasing decentralisation is crucial for success in the cryptoasset space. Hedera achieves decentralisation even in a permissioned setting through geographic distribution, independent trusted enterprise-based decision-making and a transparent governance structure, as well as a staged approach towards the future inclusion of non-Council nodes in consensus. The Council's distributed, independent and transparent governance structure was designed to address these objectives and promote greater confidence in the efficiency and decentralised nature of decision-making processes. Nevertheless, any perceived or actual deficiencies in the Hedera network's governance practices could potentially deter investment and destabilise the platform's credibility.
• Partnership Dependencies: The Hedera Council collaborates with various enterprises and industries to enhance its network utility, notably Hashgraph Foundry, Inc. (f/k/a Swirlds Labs). Any disruptions in these partnerships or failure to meet collaborative objectives could adversely affect its operational goals.
• Regulatory Risks: As a company governing a technology platform that crosses multiple jurisdictions, the Hedera Council must navigate a complex landscape of regulatory requirements, including data privacy, cybersecurity, financial regulations, securities regulations, commodities regulations, and more. Changes in legislation or noncompliance could lead to fines or restrictions on operations. For instance, as described in E.14, Hedera Council Members may filter transactions in compliance with international sanctions, which can affect the utility of HBAR for crypto asset holders in the corresponding jurisdictions.

• Pricing Volatility: Cryptoasset prices are susceptible to significant fluctuations due to market dynamics.
• Liquidity Conditions: Insufficient liquidity on exchanges or trading platforms could lead to large price swings, impacting the ability of holders to sell their assets without significant price concession.
• Market Demand: The risk that the Hedera network may not achieve expected levels of market adoption can affect HBAR's utility and value.
• Impact of Large Transactions: Large transactions by major holders (often termed as 'whales') could significantly influence the price, leading to potential manipulation or unintended price destabilisation.
• Broader Economic Conditions: Wider economic downturns or financial market instability could lead to decreased investment in cryptoassets, adversely affecting their price and liquidity.
• Regulatory Changes: Potential impacts of evolving regulatory landscapes on the offer and trading of cryptoassets.
• Scam risks: Frauds and scams related to fake crypto asset giveaways, identity theft, social engineering, and phishing schemes by malicious actors present a risk of loss for HBAR holders.
• Irreversibility risks: Payments made under coercion, deceit, by mistake, or unlawfully are irreversible. While Council nodes may filter transactions on IP for regulatory compliance, the Council does notnot have the ability to reverse transactions, delete or freeze accounts (see E.14). In this context. While a court can mandate a compensatory transaction, it lacks the technical means to implement such an order without the private keys associated with the relevant address, akin to the limitations with physical cash. These risks canbe mitigated through the use of intermediaries, particularly those that are regulated and have robust customer support. However, this approach reintroduces the conventional risks associated with dependence on third parties.
• Private Key Management Risks: Loss, theft, or improper management of private keys needed to access cryptoassets can result in irreversible loss of access to the assets.
• Custodial Risks: Private key management risks may be mitigated by resorting to custodians, however these risks are shifted then to the third party, enabling potential losses due to failures in safeguarding the cryptoassets on their side.
• Privacy Risks: HBAR transactions are publicly recorded on theHedera network, potentially exposing user activities. Hedera network accounts are pseudonymous, and addresses offer pseudonymity, but the transparent and immutable record of all HBAR transactions could allow for the development of forensic and intelligence methods that could potentially trace addresses back to realworld identities.
• Taxation risks: It cannot be guaranteed that transactions against HBAR, whether or not against other crypto assets, do not incur tax consequences.
• Regulatory risk: The lack of regulatory harmonization or the lack of regulation altogether may present additional risks to HBAR holders

• Technical Delays and Overruns: Risks of delays in development timelines or budget overruns due to unforeseen technical challenges, complexity in technology integration, or underestimation of resource requirements.
• Quality Assurance: Potential issues with software bugs, security vulnerabilities, or performance shortfalls that could emerge despite testing, particularly as new updates or features are deployed.
• Dependency on Third Parties: With the Hedera network being on a path to decentralisation, reliance on external partners or serviceproviders such as Hashgraph Foundry Inc. could introduce delays and additional risks, as failure to deliver on commitments can derail project timelines and objectives. Similarly, the independence of third parties may introduce risks in terms of public image as third parties are free to set their own communication policy.
• Adoption by Users: Risk that new features or updates are not adopted by users due to lack of perceived benefits, complexity in transition, or user resistance to change.
• Community Support: Lack of Hedera Improvement Proposals on the side of the Hedera developer community may result in a lower pace of technological progress than would otherwise be possible. Furthermore, misalignment with community expectations or failure to adequately engage community stakeholders can result in poor adoption or negative publicity.
• Market Penetration: Challenges in penetrating target markets due to strong competition, lack of market readiness, or ineffective marketing strategies.
• Human Resources: On the path to decentralisation, the Hedera Council has an everdecreasing amount of personnel, however this is still nonzero. Its (and its partners’) dependency on key personnel and the challenge of maintaining a skilled workforce in a competitivemarket. The loss of key developers or executives, at either the Hedera Council or key external partners or service providers, or difficulty in attracting talent, can impact project continuity and success

• ⅓ Attacks:If one third of the nodes (weighted by stake) werecompromised, this could potentially halt the acceptance of the correct transactions and affect fair ordering of transactions.This is exacerbated by the possibility of firewall attacks, which a malicious actor could use to separate a third of the network from the rest of it.
• Attacks on Network Proxies and Specific Hedera Services: Despite the robustness of the Hedera mainnet, proxies providing access to the network could be subject to vulnerabilities, enabling smart contract exploits (HSCS).
• Code Quality and Bugs: Software bugs and defects in new releases orupdates could compromise system functionality, security, and user trust.
• Protocol Updates: Updates to the Hedera protocol required cryptographicallysigned transactions, which introduces risks.
• Weighted voting cryptography: Enabling weighted voting in the virtual consensus algorithm, whereby node votes are weighted by their stake, requires modifications to the current cryptography of the Hedera network – which currently relies on rounding of the stake and is thus not entirely precise. Delays in the technical project of achieving these modifications could potentially delay the depermissioning of the network.
• Quantum Computing Risks: As most systems on the internet, the Hedera network relies heavily on cryptography, notably publickey cryptosystems based on classical assumptions. If quantum computing were to break classical assumptions, this would posea risk to the Hedera network’s cryptography that would need to be managed.
• Sharding Risks: While highly scalable on its own, eventually the Hedera network will scale via sharding. Shards will require some technical breakthroughs, delays which would affect the technological pace of the network. Furthermore, each shard will individually be subject to the same risks that currently affect the network as awhole (e.g. every individual shard will be susceptible to ½ attacks andthis will need to be managed).
• Interoperability Risks: Success for the Hedera network as a crypto asset project is more likely if the protocol is fully interoperable with other projects. Delays in achieving interoperability would concordantly harm the success of the network as a whole.
• Other attacks: Certain conceivable attacks targeting the Hederanetwork are not failures of its consensus mechanism, as they would be equally effective in a singleserver setup. For instance, if attackers could control internet traffic and delay messages, they could isolate nodes entirely by disconnecting them from the rest of the internetto ensure a particular set of transactions never reaches the nodes at all, similar to executing a denial of service attack. Such a strategy would disrupt communication regardless of whether the attacked nodes were interacting with a decentralised network or a central server, making it a broader internet security issue rather than a specific flaw in the consensus system.

• IssuerRelated Risks:
  • The Hedera Council maintains robust financial reserves and employs stringent budgeting practices to manage its Treasury effectively. This ensures long-term sustainability and buffers against potential decreases in network usage or revenue.
  • Regular internal audits assess and enhance the effectiveness of operational controls, reducing the risk of fraud and operational errors.
  • The Hedera Council commits to transparency in its decision-making processes. Regular disclosures on governance practices and strategic decisions are made to keep stakeholders informed and involved. All meeting minutes from Hedera Council Meetings are not just published but recorded on-chain.
  • The Hedera Council continually works towards increasing the decentralisation of the Hedera network. This includes expanding the number of nodes and distributing governance roles across a broader set of stakeholders to reduce central points of failure and improve network resilience.
  • By engaging with a variety of partners across different sectors and regions, the Hedera Council spreads its dependency risks and enhances its operational resilience.
  • The Hedera Council’s legal team proactively engages with regulatory developments and ensures compliance across all jurisdictions in which it operates.
  • Hedera Council signers follow strict operational security procedures including key management and single-purpose laptops.
• CryptoAssetsrelated Risks: The Hedera Council does not seek to influence the price of HBAR, which is subject to forces of supply and demand. However:
  • The Hedera Council’s communication policy seeks to educate HBAR holders and prospective holders about the various market risks.
  • The Hedera Treasury Allocation Plan has been designed carefully to avoid disrupting the market.
  • The Hedera Council’s Policy team is constantly engaging with regulators to minimise the negative aftereffects of the evolving [regulatory landscape].
• Project ImplementationRelated Risks:
  • Continuous security assessments and updates fortify the Hedera network’s defences against new vulnerabilities.
  • The Hedera ecosystem players maintain active channels for community interaction and feedback, ensuring that the community’s voice is heard and considered in project development.
  • Hedera Council’s partners actively work to encourage developer activity and Hedera Improvement Proposals.
  • Hedera Council actively works to reduce any dependencies on particular partners.
  • Hedera Council upholds the highest Human Resources standards and constantly works to achieve the highest level of operational efficiency and quality.
• TechnologyRelated Risks:
  • The Hedera Council strictly vets new Council members and will only enable full depermissioning of the network under conditions that would make a 1/2 attack unfeasible.
  • Hedera Council and Hashgraph Foundry constantly conduct internal security audits to identify and rectify vulnerabilities before they can be exploited.
  • A rigorous code review process involving multiple senior developers is followed to catch potential bugs before software release.
  • Hedera Council actively maintains a bug bounty programme.
  • Hedera network adheres to the CNSA standard, which the US government employs to secure its Top Secret data. This standard mandates the use of at least 256-bit AES keys in TLS connections and 384-bit SHA-2 hashes. SHA-384 is considered "quantum resistant" per the CNSA 2.0 Quantum Computing guidance published in Dec 2024. These larger key sizes make AES and SHA-2 typically regarded as secure against potential future quantum computers, even those of considerable size. If required, new cryptographic algorithms (including those tested by NIST as part of their post-quantum work) can be introduced in Hedera without undertaking a hard fork, as demonstrated by the introduction of ECDSA_SECP256K1 support post-network launch.
  • The Hedera Council team and its partners actively work to facilitate interoperability, make the technical breakthroughs that will enable sharding, and lay the groundwork for post-quantum cryptography on the Hedera network.