> ## Documentation Index > Fetch the complete documentation index at: https://docs.monad.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Staking > How Monad's staking system works Monad uses staking to determine validator voting weights and each epoch's leader schedule in [MonadBFT](/monad-arch/consensus/monad-bft). 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](/reference/staking/overview) and [API](/reference/staking/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`](/reference/staking/api#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 | Constant | Meaning | Value | | ------------------------ | ----------------------------------------------------------------------- | -------------- | | `BOUNDARY_BLOCK_PERIOD` | Blocks from boundary block to boundary block | 50,000 blocks | | `EPOCH_DELAY_ROUNDS` | Rounds between the boundary block and the start of each epoch | 5,000 rounds | | `WITHDRAWAL_DELAY` | Number of epochs before unstaked tokens can be withdrawn | 1 epoch | | `MIN_AUTH_ADDRESS_STAKE` | Min MON self-delegated by a validator to be eligible for the active set | 100,000 MON | | `ACTIVE_VALIDATOR_STAKE` | Min total MON staked with a validator for active set eligibility | 10,000,000 MON | | `ACTIVE_VALSET_SIZE` | Number of validators in the active set | 200 | | `REWARD` | MON reward per block | 25 MON |