Updated July 27th, 2022, to reflect the CoinCom vote to reduce the minimum node stake value from 1/2 of the max node stake to 1/4 of the max node stake
First phase allows ecosystem to build tooling, and for users to test functionality without earning rewards
Hedera is a proof-of-stake network, meaning it does not require mining to solve computational problems and deliver proof of work for reward. Instead, Hedera’s design uses the value of a scarce, “pre-minted” resource ($HBAR), staked to network nodes, to achieve consensus and protect the network against certain forms of cyberattack, including Sybil attacks. Enabling native staking, therefore, is essential for the Hedera network to continue along its path to decentralization and to incentivize staking behavior to protect the network from attack.
Currently, Hedera network nodes are operated by members of the Hedera Governing Council, and each node has an equal stake. As the network is further decentralized and non-council member nodes are allowed to participate, it becomes critical to permit users to choose to which node(s) they want to stake their hbars. For permissionless networks, anyone can operate a node and participate in network consensus. As such, public, permissionless proof-of-stake networks need a scarce resource (usually the network’s native cryptocurrency) to secure the network against such attacks. Rather than each node having a vote weight proportional to hashing power, like in proof-of-work, a node’s ability to influence consensus is proportional to the number of coins (in this case, hbars) staked to a node. Hedera achieves consensus on a transaction when the voting involves more than two-thirds of the network’s voting power. An entity, then, would need to attain one-third of the total voting power (i.e. one-third of the staked hbars) to disrupt the network.
The Hedera mainnet codebase has now been updated to enable the first phase of native staking and allows users to select nodes to which to stake their account. In phase II, the amount of hbars staked per node will affect its consensus weight (voting power), updated monthly. In phase IV, node stake will be updated on a 24-hour basis, as stated in HIP-406.
The staking functionality is now available and live on both the Hedera testnet and mainnet, as of July 21, 2022. In phase I, users will technically be able to stake their account to mainnet nodes but this will not contribute to a node’s consensus weight (voting power). This initial technical availability release does not reward participants for staking, but enables a level playing field whereby all market participants have the possibility to join the staking program, and avoids giving an unfair advantage to the first few who stake.
During this phase, supported exchanges and wallets will be able to integrate the staking functionality to provide account holders an easy way to stake their hbars. In addition, web applications for delegating stake will likely be built for utilization by the retail ecosystem. During this phase, there will be visibility of stake per node, and staking to a node will affect its consensus weight (voting power) with monthly updates.
The Hedera Governing Council will determine when the Hedera ecosystem has reached a minimum viable set of integrations to enable staking rewards. Once this is determined, the council (through CoinCom) will vote to update the reward rate, and subsequently, the mainnet will be updated with the agreed-upon reward rate.
Once updated, the staking reward account (0.0.800) will be eligible to distribute rewards earned by stakers, once the rewards threshold of 250M total hbars has been met. Rewards will continue to be distributed even if, after this time, the balance of account 0.0.800 goes below 250M.
Earned rewards are transferred to eligible accounts staked to a node through one of many transactions. Both the account eligibility requirements and the types of transactions that can be used to claim rewards are described in the staking documentation.
The Council (through CoinCom) has voted to implement a maximum cap of 6.5% annual reward rate. The actual reward rate will vary depending on how many hbars are staked for rewards, but the rate will not exceed the cap.
In this phase, 24-hour updates for visibility into stake per node and the node uptime feature will be released. This means that instead of updating node stake visibility on a monthly basis, node stake visibility will be updated on a 24-hour epoch interval. When the uptime feature takes effect, staked accounts will not earn rewards when nodes are unable to participate in consensus (unavailable or offline).
Accounts that will contribute to staking but have pledged to not receive rewards into the foreseeable future (even when rewards are enabled) include those owned by Hedera (Treasury), Swirlds, and Swirlds Labs. In aggregate, these accounts control more than half of the total minted supply of hbars, ensuring that enough hbars are staked for network security.
The staking architecture is based on the original design defined in the Hedera Hashgraph whitepaper. In the future, the reward mechanism will be enabled, so those who choose to stake their hbars can earn rewards, if they choose, for their contribution to the operation and security of the Hedera network.
No minimum amount of hbars will be needed for hbar holders to participate in staking and earn rewards. There is no “bonding”, slashing, or lock-up periods, but there is a minimum staking period of 24 hours. Accounts staked during a fraction of one of those periods have no effect on consensus, and so will earn no rewards.
This staking system offers additional unique functionality: indirect staking. If account A stakes to node N, then the stake increases the consensus weight of N, and account A is rewarded for every 24-hour period that it stakes. If account A stakes to account B, and account B stakes to node N, then the stake from both A and B will increase the consensus weight of N, but the rewards for both A and B will be received by B.
The Hedera Governing Council Treasury Management and Coin Economics Committee (CoinCom) has defined and approved the following:
Max stake (the maximum amount of hbars a single node can have staked to it for contributing to consensus): If a node has more than the max stake value, the node will be treated as if its stake is equal to the max stake. CoinCom voted for the max stake value to be the total number of hbars divided by the total number of nodes in the network. For example, 50 billion hbars/26 nodes would have a maximum stake of 1,923,076,923.0769231 hbars. The max stake value of each node will change every time a node is added to the network.
Min stake (the minimum amount of hbars a single node must have staked to it for participating in consensus): If a node has less than the min stake value, the node will be treated as if it has zero stake. On July 26th, 2022, CoinCom voted to reduce the minimum node stake value from 1/2 of the max node stake, to 1/4 of the max node stake. Using the same example cited above, 50 billion hbars/26 nodes, divided by four, would have a minimum stake of 480,769,230.769230 hbars.
The current min and max stake values for Mainnet nodes will adjust to changes in the network; the current values reflect the network of Governing Council member nodes. The Governing Council may modify these values in the future to accommodate for community nodes and permissionless nodes.
The staking rewards account (0.0.800) threshold value (the value that needs to be met before it begins distributing rewards to eligible stakers): This threshold value was voted to be 250M hbars. Once this threshold is met and the reward rate is updated, the rewards account will automatically start distributing rewards to eligible stakers.
Network and service fees will continue to route to account 0.0.98 (Hedera Treasury) and node fees will continue to route to individual node operators. More information about the types of fees per transaction can be found here.In the future, the Hedera Governing Council may vote to route network and service fees, originally intended for the Hedera treasury (0.0.98), to the staking rewards account (0.0.800) for distribution to stakers.
For more information about staking on Hedera, please visit: https://hips.hedera.com/hip/hip-406#abstract
If you don’t have slashing, how do you deal with the issues of ‘bad validators’ or ‘lazy votes’?In the hashgraph algorithm, there's no such thing as “casting lazy votes”. In fact, there's no vote casting at all. Because it uses virtual voting. As long as a node creates judges in each round, all the other nodes will consider it to be virtually voting, without it actually doing any real voting.
Instead, a node’s contribution is measured by whether it creates a judge in many rounds. So we have said that those staking to a node will receive rewards only if it has a judge in a high enough fraction of the rounds; it also must have a consistent signature for those rounds. If a node achieves that, then it is doing all of the gossip and consensus work required of it. That is why we have always stated there will be no slashing on Hedera.
In addition, on Hedera, stake can be delegated. This poses a severe threat to validators that have acted maliciously in the past because, regardless of past economic penalties, no one will delegate their stake to them again, so they will not reach the minimum stake threshold to start benefiting from their validator’s duties.
What are the DoS impacts of a high volume of inconsistent signatures?One advantage of being ABFT is that if less than 1/3 of the nodes are affected by a DoS attack, it has no effect, and doesn't slow down the network appreciably. In addition, these nodes don’t get rewarded, and everyone will see that they're out of sync. And if they are honest nodes, then they automatically reconnect with another node to fix their problem. In addition, it is cryptographically impossible for them to fool the mirror nodes.