A list of whitepapers created by Hedera that detail its technology and economic decision making. PDFs are hashed and timestamped using Hedera Consensus Service with ProvenDB.
First published: March 13, 2018Last updated: August 15, 2020
Distributed ledger technologies (DLT) have the potential to disrupt and transform existing markets in multiple industries.
However, in our opinion there are five fundamental obstacles to overcome before distributed ledgers can be widely adopted across industries and geographies: (1) Performance, (2) Security, (3) Governance, (4) Stability, and (5) Regulatory Compliance.
The Hedera whitepaper examines these obstacles and discusses why Hedera is ideally suited to support a vast array of applications and become the world’s first mass-adopted public distributed ledger.
First published: December 7, 2020Last updated: December 7, 2020
This paper provides an overview of the two primary models Hedera supports for tokenization – natively on Hedera, using the new Hedera Token Service and in a permissioned network setting, using Hedera Consensus Service. Tokenization on Hedera introduces the technical fundamentals of each and aims to assist token issuers with determining the deployment model most appropriate for their use case.
The Consensus Service proof-of-concept use case is providing custom Hyperledger Fabric networks with decentralized consensus on the validity and order of blockchain transactions without the need to configure a RAFT1 or Kafka2 ordering service. Additional use cases include, but are not limited to, financial markets, matching engines (like those used in Uber or AirBnb), or supply chain negotiations (e.g., several competing factories bidding on parts from several competing parts suppliers).
First published: June, 2021Last updated: March, 2023
Hedera believes that complete decentralization is paramount for the efficacy of a public distributed ledger’s adoption by businesses, individuals, universities, governments, non-profit organizations, and more. Decentralization of consensus and reaching permissionless network nodes is one of the four parts of that complete path. This whitepaper defines decentralization requirements when it comes to nodes on the Hedera network and describes how Hedera will further continue progressing along its path to meet them.
First published: June 13, 2020Last updated: June 13, 2020
The Hedera Consensus Service (HCS) enables a decentralized architecture that can help solve for certain data privacy compliance challenges presented by naïve implementations of distributed ledger technology (DLT), while making possible new data privacy compliance mechanisms that are consistent with principles of user empowerment and control over how their identity attributes are collected, stored, processed, and shared. These principles are central to the European Union’s General Data Protection Regulation (the GDPR) and other data privacy regulation frameworks around the globe.
This publication is intended to provide an overview of some of the features and functionality of HCS and should not be considered or relied upon as legal advice. Data privacy regulations continue to evolve, may vary significantly between jurisdictions, and can be ambiguous when applied to uses of emerging technology. Other obligations and regulations not discussed in this paper may apply to participants in the Hedera ecosystem depending on the context of their participation in the Hedera Network or characteristics of their application. Developers utilizing HCS should seek legal and compliance advice from an independent qualified professional.
First published: November 11, 2021Last updated: November 11, 2021
This whitepaper serves as a guide for understanding key privacy and data protection concepts to guide you when building dApps on any distributed ledger technology network. This paper consists of three sections: Global Privacy Requirements, Architectural Considerations, and Inheriting Trust via Hedera.
First published: April 20, 2020Last updated: May 16, 2020
Atomic broadcast protocols are increasingly used to build distributed ledgers. The most robust protocols achieve byzantine fault tolerance (BFT) and operate in asynchronous networks. Recent proposals such as HoneyBadgerBFT (ACM CCS ‘16) and BEAT (ACM CCS ‘18) achieve optimal communication complexity, growing linearly as a function of the number of nodes present. Although asymptotically optimal, their practical performance precludes their use in demanding applications.
Further performance improvements to HoneyBadgerBFT and BEAT are not obvious as they run two separate sub-protocols for broadcast and voting, each of which has already been optimized. We describe how hashgraph — an asynchronous BFT atomic broadcast protocol (ABFT) — departs in structure from prior work by not using communication to vote, only to broadcast transactions. We perform an extensive empirical study to understand how hashgraph’s structure affects performance. We observe that hashgraph can improve latency by an order of magnitude over HoneyBadgerBFT and BEAT, while keeping throughput constant with the same number of nodes; similarly, throughput can increase by up to an order of magnitude while maintaining latency.
Furthermore, we test hashgraph’s capability for high performance, achieving over 100,000 tps with less than 5 second latency in some instances.
First published: September 15, 2019Last updated: June 3, 2020
For more current, robust, transparent, and verifiable information on the circulating supply, allocation, and release schedule of hbars, please read the Hedera Treasury Management Report.
This information is also tracked in real-time by HashScan, a third-party network explorer; however, Hedera does not guarantee the accuracy of any third-party data.
This paper describes how hbars are used on the Hedera network, their role in achieving consensus on and securing transactions, and the expected distribution of Hedera’s fixed supply of 50 billion hbars. The information presented herein is dated as of June 3, 2020 and many of the data entries have changed since its publication. It is provided for informational and historical purposes only.