Skip to main content
Monad uses staking to determine validator voting weights and each epoch’s leader schedule in MonadBFT. Validators must stake at least a minimum amount, and others can delegate to them. For a developer-oriented guide to interacting with the staking precompile, see the documentation overview and API.

​
Validator set

To be part of the active validator set, a validator must meet all of the following criteria:
  • Self-delegation: the validator’s authAddress must have self-delegated at least MIN_AUTH_ADDRESS_STAKE (100,000 MON)
  • Total stake: the validator must have total delegation of at least ACTIVE_VALIDATOR_STAKE (10,000,000 MON)
  • Rank: the validator must be in the top ACTIVE_VALSET_SIZE (200) validators by stake weight
Validators that fall below these thresholds are removed from the active set at the next epoch boundary.

​
Rewards and commission

When a block is produced, the leader who produced it earns a block reward from two sources:
  1. Inflationary reward — a fixed REWARD of 25 MON per block, minted by the protocol
  2. Priority fees — the priority fees from all transactions in the block

​
Commission

Each validator sets a commission rate (0%–100%) that determines what fraction of the inflationary block reward they keep before distributing the remainder to delegators. The remainder is distributed pro rata by stake weight. As a delegator, your share of a block’s reward is proportional to your stake relative to the validator’s total stake. Example: Suppose you have delegated to a validator and comprise 20% of that validator’s total stake. The inflationary block reward is 10 MON and the commission is 10%. You receive:
10 MON × 90% × 20% = 1.8 MON

​
Priority fees

Currently, priority fees go only to the validator. Validators may choose to share priority fees with delegators (including themselves) by calling the externalReward method on the staking precompile. Commission is not deducted from external rewards.

​
Claiming and compounding

Each delegation accumulates rewards over time. Delegators can either:
  • Claim rewards — withdrawn to the delegator’s account immediately
  • Compound rewards — added to the delegation, increasing stake weight (follows the standard epoch timing rules described below)

​
Epochs and boundaries

An epoch uses one set of delegations and leader validators for its entire duration. Every 50,000 blocks (the BOUNDARY_BLOCK_PERIOD) is a boundary block that commits the upcoming staking changes and the validator set to be used in the next epoch. Boundary blocks happen approximately every 5.5 hours. The next epoch does not start immediately at the boundary block, but after a 5,000-round delay (EPOCH_DELAY_ROUNDS) to allow all nodes to update their epoch information. timeline showing the placement of boundary blocks within an epoch

​
Timing of staking actions

Most staking actions take effect after they are committed in a boundary block and the next epoch starts. The exceptions are claimRewards() and externalReward(), which take effect immediately. As an example, consider delegate() during epoch #4:
  • If the delegate() takes place before the boundary block for epoch #5, the stake will be included in epoch #5.
  • If the delegate() transaction is in the boundary block itself, it will not be included in epoch #5 (the snapshot is taken at the start of the block, before user transactions). The delegation will be picked up in the boundary block for epoch #6.
  • If the delegate() transaction is after the boundary block but before the end of epoch #4, the delegation will take effect in epoch #6.
The BOUNDARY_BLOCK_PERIOD is denominated in blocks, while EPOCH_DELAY_ROUNDS is denominated in rounds. If perfect consensus is achieved, these increment at the same rate. However, upon a failed block proposal (e.g. timeout), the round increments while the block does not.

​
Execution, snapshot, and consensus views

The staking system maintains three views that staking state passes through:
  1. Execution view — the real-time state. When validators are added, delegations change, or any staking transaction happens, the execution view is updated immediately.
  2. Snapshot view — at the start of each boundary block, the current execution view is copied into the snapshot view. Any transaction changes after this point will not affect the following epoch. The snapshot now matches what the next epoch will look like.
  3. Consensus view — after EPOCH_DELAY_ROUNDS (5,000 rounds) from the boundary block, the new epoch starts and the snapshot view is copied into the consensus view. The consensus view holds the validators and voting stake weights being used by the consensus system for the remainder of the epoch.

​
Slashing

Robust logging provides accountability for malicious, slashable offenses. However, automated in-protocol slashing is not currently implemented.

​
Constants

ConstantMeaningValue
BOUNDARY_BLOCK_PERIODBlocks from boundary block to boundary block50,000 blocks
EPOCH_DELAY_ROUNDSRounds between the boundary block and the start of each epoch5,000 rounds
WITHDRAWAL_DELAYNumber of epochs before unstaked tokens can be withdrawn1 epoch
MIN_AUTH_ADDRESS_STAKEMin MON self-delegated by a validator to be eligible for the active set100,000 MON
ACTIVE_VALIDATOR_STAKEMin total MON staked with a validator for active set eligibility10,000,000 MON
ACTIVE_VALSET_SIZENumber of validators in the active set200
REWARDMON reward per block25 MON