Harmony
Support ForumGithubTelegramDiscord
  • Welcome
  • 🎶General
    • Introduction
      • What is Harmony?‌
      • Roadmap
      • Strategy & Architecture
      • Study Materials
      • FAQ
    • Technology
      • Key Features
      • Randomness
      • Sharding
      • Consensus
      • Effective Proof-of-Stake
      • Tokenomics
      • Transactions
    • LayerZero Bridge
      • Important Notice
      • Bridge tutorial
      • FAQ
        • What token will I get after the bridge
        • How to find a bridged token address
    • Ecosystem
      • Wallets
        • 1Wallet
        • Gnosis Safe
        • Hardware Wallets
          • Trezor
          • Ledger Nano
            • Ledger with Metamask
            • Download & Setup
            • Ledger with HMY CLI
            • Ledger with Staking Dashboard
              • Sign In With Ledger
              • Sending transactions via Ledger
              • Staking Transactions via Ledger
          • Safepal
            • Download & setup
            • Create/import account
            • Send transaction
        • Browser Extension Wallets
          • Metamask
            • Installing MetaMask
            • Adding Harmony
            • Create a New Account
            • Sending & Receiving
            • Adding Custom Harmony Tokens
            • Import an Account
          • Math Wallet
            • Download & Setup
            • Create/Import/Export Wallet
            • Sending Transactions
            • Staking
            • Collecting Rewards
            • Undelegating
          • Harmony Chrome Extension Wallet
        • Desktop Wallets
          • Guarda Wallet
          • Staking4All Wallet
        • Mobile Wallets
          • Metamask Wallet
          • Blits Wallet
          • Cobo Wallet
          • Frontier Wallet
          • Guarda Wallet
          • Infinity Wallet
          • ONTO Wallet
          • Sef Wallet
          • Trust Wallet
          • Trustee Wallet
        • Web Wallets
          • Guarda Wallet
        • HMY CLI (Harmony Command Line Interface)
          • Download & Setup
          • Create or Import Wallet
          • Sending Transactions
          • Staking Transactions
          • Querying Balances
          • Querying the Blockchain
          • List of Transaction Error Messages
          • Cookbook
          • Other CLI References
      • DApps
        • User Guide
        • DeFi
          • Sushi
          • Onsen
        • CLI 1Wallet User Guide
        • Media
          • Timeless
        • FAQ
        • NFTs
      • Partners
        • Exchanges
        • Fiat Gateways
        • DeFi Protocols
      • Integrations
      • Cross-Border Finance
      • DAOs
        • Components & Tools
          • Snapshot
        • Community DAO
        • Validator DAO
        • Developer DAO
    • Community
  • 🏗️Developers
    • Getting Started
      • Network & Faucets
      • List of RPC Providers
      • Remix IDE
      • Dev Environment Setup
      • Ethereum Compatibility
    • Deploying on Harmony
      • Using Remix
        • Ethereum Remix
        • Harmony Remix
      • Using Truffle
      • Using Hardhat
      • Using Web3
      • Using Harmony-JS
        • Setup
        • Compile & Deploy
        • Demo: Deploying an Ethereum Smart Contract on Harmony
      • Deploy HRC20
      • Smart Contract Verification
    • SDK
      • Web3.js
        • Using Web3.js to Send Transactions on Harmony
        • Find the last transaction
      • JavaScript SDK
      • Go CLI
      • Java SDK
      • Python SDK
      • Harmony Ethers.js Wrapper
    • API
      • Methods
        • Account Methods
          • hmy_getBalanceByBlockNumber
          • hmy_getTransactionCount
          • hmy_getBalance
        • Filter Methods
          • hmy_getFilterLogs
          • hmy_newFilter
          • hmy_newPendingTransactionFilter
          • hmy_newBlockFilter
          • hmy_getFilterChanges
          • hmy_getLogs
        • Transaction Related Methods
          • hmy_getStakingTransactionByBlockHashAndIndex
          • hmy_getStakingTransactionByBlockNumberAndIndex
          • hmy_getStakingTransactionByHash
          • hmy_getCurrentTransactionErrorSink
          • hmy_getPendingCrossLinks
          • hmy_getPendingCXReceipts
          • hmy_getCXReceiptByHash
          • hmy_pendingTransactions
          • hmy_sendRawStakingTransaction
          • hmy_getTransactionsHistory
          • hmy_sendRawTransaction
          • hmy_getTransactionReceipt
          • hmy_getBlockTransactionCountByHash
          • hmy_getBlockTransactionCountByNumber
          • hmy_getTransactionByHash
          • hmy_getTransactionByBlockNumberAndIndex
          • hmy_getTransactionByBlockHashAndIndex
          • hmy_getBlockByNumber
          • hmy_getBlockByHash
          • hmy_getBlocks
        • Contract Related Methods
          • hmy_estimateGas
          • hmy_getStorageAt
          • hmy_call
          • hmy_getCode
        • Protocol Related Methods
          • hmy_isLastBlock
          • hmy_epochLastBlock
          • hmy_latestHeader
          • hmy_getShardingStructure
          • hmy_blockNumber
          • hmy_syncing
          • hmy_gasPrice
          • net_peerCount
          • hmy_getEpoch
          • hmy_getLeader
        • Staking Related Methods
          • hmy_getCirculatingSupply
          • hmy_getTotalSupply
          • hmy_getStakingNetworkInfo
          • hmy_getAllValidatorInformation
          • hmy_getAllValidatorInformationByBlockNumber
          • hmy_getCurrentUtilityMetrics
          • hmy_getDelegationsByValidator
          • hmy_getDelegationsByDelegatorAndValidator
          • hmy_getDelegationsByDelegator
          • hmy_getValidatorMetrics
          • hmy_getMedianRawStakeSnapshot
          • hmy_getElectedValidatorAddresses
          • hmy_getAllValidatorAddresses
          • hmy_getCurrentStakingErrorSink
          • hmy_getValidatorInformation
          • hmy_getValidators
          • hmy_getSignedBlocks
          • hmy_isBlockSigner
          • hmy_getBlockSigners
        • Tracing Methods
          • trace_block
          • trace_transaction
      • Sample Code
    • Tools
      • Harmony VRF
      • The Graph
      • Envio
      • Ganache
        • Harmony Ganache
      • Harmony-React
      • Oracles
        • Band Protocol
      • Smart Contract Verification
    • Tutorials
      • Deploying HRC20
      • Deploying HRC721/NFT
      • The Graph - Subgraphs
        • Building & Deploying Subgraph (local node)
      • Using Band Oracle
      • Using Crosschain API
        • Scripts
        • Testing
        • Webserver
      • Using Web3.py & Pyhmy
      • Using IPFS & Filecoin
        • Using IPFS
        • Using NFT.storage
      • Indexing HRC20 with Envio
      • Building a Simple Metaverse Contract
      • Building a Simple Bridge with Ethereum
      • Staking for Multisig
    • DApp Examples
      • DApp Samples
      • Games
        • Harmony Puzzle
      • Cross-Chain
      • DeFi
      • Hackathons
        • DevPost
        • Hack the Horizon
      • Others
    • Wallets
      • Metamask
        • Interacting With Metamask
        • Using Metamask with Harmony Smart Contracts
        • Add or Switch to Harmony chain on Metamask
      • Harmony Chrome Extension Wallet
      • Math Wallet
      • WalletConnect
    • Harmony Stack and Projects
  • 🌏Network
    • Governance
      • Network Governance
        • Voting via Governance App
        • Voting via HMY CLI
      • HRC-20 Governance
      • FAQ
    • Validators
      • Terms & Concepts
        • Validator, BLS key, Instance
          • Shard Assignment
        • Slots Bidding and Election
        • Effective Proof-of-Stake
        • Block Reward
        • Epoch Transition
        • Slashing
        • Undelegation
      • Server Setup
        • Requirements
        • Cloud Guides
          • Digital Ocean
          • Vultr
          • AWS
          • Google Cloud
        • Raspberry Pi Guide
      • Node Setup
        • 1. HMY CLI Download
        • 2. Setting up BLS Keys
        • 3. Syncing DB
        • 4. Installing & Updating
          • Installing A Node
            • Using Node Binary
            • (Deprecated) Using AutoNode
              • Install & Run
              • Update
              • Monitor
              • BLS Key Management
              • Collect Rewards
              • Maintenance
              • Troubleshoot
              • Extra
            • (deprecated) Using Node.sh
          • Upgrading A Node
            • Using Node Binary
            • Using AutoNode (deprecated)
            • Using Node.sh (deprecated)
          • Checking A Node
      • Creating A Validator
      • Managing A Validator
        • Checking Validator Information
        • Changing Validator Information
        • Delegating To A Validator
        • Undelegating From A Validator
        • Check Your Delegations
        • Collecting Rewards
        • Adding A Validator Logo
      • Staking Dashboard Basics
      • Validator Information Terms
      • Validator Security Tips
      • Slashing and Uptime
      • Monitoring
        • Node Sync
        • Prometheus & Grafana
        • Network Status
      • Troubleshooting
        • Why am i not Elected?
        • Frequently Asked Questions (FAQ)
      • Tools
        • Telegram Bots
        • Dashboards
        • Reward Calculators
        • Text User Interface (TUI)
        • HMY Bidder
        • Mobile Apps
          • One Validator Dashboard
          • Termux
    • Delegators
      • Introduction
      • Staking
        • Via Browser
          • Staking Dashboard
          • Staking Transactions
          • Sending Transactions
        • Via Mobile
        • FAQ
      • Redelegation
      • Informational Videos
Powered by GitBook
On this page
  • Effective Stake
  • Shard Committee and Voting Power
  • Block Reward
  • Double Sign Slashing
  • Uptime and Unavailability Penalty

Was this helpful?

Export as PDF
  1. General
  2. Technology

Effective Proof-of-Stake

PreviousConsensusNextTokenomics

Last updated 1 year ago

Was this helpful?

Harmony is one of the first production mainnets to feature a fully sharded PoS architecture. Across the 4 shards in Harmony mainnet, blocks are produced every 2 seconds and cross-shard transactions are finalized in 2 block times.

Harmony’s Effective Proof-of-Stake (EPoS) is the first staking mechanism in a sharded blockchain that achieves both security and decentralization. EPoS allows staking from hundreds of validators and the unique effective stake mechanism reduces the tendency of stake centralization. Meanwhile, stake delegation, reward compounding, double-sign slashing, and unavailability checking are also supported.

Our token economics model incentivizes early stakers with higher rewards to bootstrap the network successfully. For those validators or delegators who would like to join , this guide will help you get started and learn about how everything works.

Effective Stake

Let’s call the bid price of the elected BLS keys the raw stake. The effective stake of an elected BLS key is a bounded value on its raw stake with a threshold around the median bidder’s raw stake (denoted as median_stake in the picture below). The upper threshold is 115% of the median_stake and the lower threshold is 85% of the median_stake. For a key with raw stake that’s out of bound of the threshold, its effective stake will be bounded by the corresponding threshold, otherwise, the effective stake is the same as the raw stake.

The effective stake of each BLS key is determined at the last block of an epoch during the election process and will stay the same throughout the next epoch.

Shard Committee and Voting Power

After the election and shard assignment, the BLS keys assigned in a shard become the committee of that shard. The voting power of an elected BLS key in a committee is the metrics used to measure the key’s weight in the consensus voting process. The total voting power of a shard committee is always 1.0 (or 100%). The consensus of a committee is only reached if more than 2/3 of the voting power is collected in the votes.

Each BLS key in the committee has a certain voting power proportional to the share of its effective stake among the whole committee. For example, if the sum of the effective stake of all the keys in the committee is 10k ONE, a BLS key with effective stake of 1000 ONE will have voting power 0.1 (or 10%).

Block Reward

For each of the blocks produced and confirmed within a shard, it should contain signatures from the keys with more than 2/3 of the total voting power of the shard committee. Each confirmed block will produce 7 ONE as block reward for the validators behind the committee. The 7 ONE is initially allocated to all the validators whose BLS key(s) signed on the block, proportionally to the voting power of the key(s) that signed.

The allocated block reward for a validator will be further distributed to delegators proportionally to their stake after the commission fee is charged. For example, a validator with a commission rate of 25% got allocated 4 ONE for a block it signed. The validator staked 1000 ONE itself and it has 2 delegations each with 1000 ONE. The block reward distribution for this validator works as follows:

  1. The commission fee of 1 ONE (4 ONE * 25%) is cut from the original reward and credited to the validator.

  2. The rest of the reward of 3 ONE is then distributed to all the stakers (including both the validator and its delegators) proportionally based on their stake. Since the stakers (the validator and the two delegators) each staked/delegated 1000 ONE, they each receive 1 ONE in the reward distribution.

Double Sign Slashing

If any BLS key(s) are detected signing conflicting blocks (i.e. blocks with the same height and view ID but with different block hashes), the validator will be slashed and forever banned from the network. When a validator is slashed, a certain percentage (i.e. slashing rate) of staked tokens from the validator and its delegators will be forfeited, of which half will be burnt and another half will be credited to the reporter of the double sign event.

The slashing rate is calculated by simply summing all the voting power of the double signing keys with a minimum of 2%. For example, if 3 BLS keys with voting power of 3%, 3% and 4% double signed at the same time, 10% of all staked tokens will be slashed on the validators who hold the 3 BLS keys.

Uptime and Unavailability Penalty

The elected validators are obligated to validate blocks with their elected BLS keys. In every epoch, an elected validator should sign more than 2/3 of the signatures that its BLS keys are asked to sign.

The signing performance is represented by a percentage value called uptime. A validator’s uptime is the ratio of the number of signatures its elected BLS keys signed over the total number of signatures the keys should sign. For example, a validator has 2 elected BLS keys and each of the keys is presented 100 blocks to sign. In the final tally, the first key signed 70 blocks and the second key signed 80 blocks. Overall, the validator’s uptime is (70+80) / (100*2) = 75%.

At the end of each epoch, the validators with uptime of no more than 2/3 (66.66%) will have their status set to “Inactive” and be ruled out from the new election. For these inactive validators, they are required to manually set their status to “Active” by sending an EditValidator transaction in order to participate in future elections. We encourage validators to be proactive in maintaining a high uptime to ensure they remain elected and earn the most block reward possible.

Effective stake is a new measure introduced in EPoS in order to prevent stake centralization and still provide capitalistic fairness. For exactly how it achieves that, is the design rationale behind it.

Effective Stake is Bounded around Median Stake
🎶
here
Harmony Open Staking
The Definitive Guide to Harmony Open StakingMedium
Logo