Mint and configure tokens and accounts.
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.
Last 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 Hashgraph is ideally suited to support a vast array of applications and become the world’s first mass-adopted public distributed ledger.
Last updated: December 7, 2020
This paper provides an overview of the two primary models Hedera Hashgraph 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.
Last updated: June 3, 2020
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 and is currently undergoing a thorough review in preparation of a new, more robust, transparent, and verifiable reporting mechanism.
For more current information on Hedera’s monthly distributions, please click here.
For more current information on the circulating supply of hbars, please click here. This information is also tracked in real time by hash-hash.info, a third-party data provider; however, Hedera does not guarantee the accuracy of any third-party data.
Last 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.
Last 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.