Staking

Monad is a proof-of-stake blockchain. Validators stake MON to participate in consensus and earn block rewards. Token holders who don't run a validator can delegate their MON to a validator, earning a share of that validator's rewards proportional to their stake.

This article explains the mechanics of staking from a delegator's perspective: when actions take effect, how rewards work, and what happens during undelegation and withdrawal.

Native delegation

Monad has native delegation built into the protocol. Any token holder can delegate MON to a validator directly, without running a node or using a third-party protocol.

This is a meaningful difference from Ethereum, where the protocol has no delegation mechanism. To stake on Ethereum, a user must either run their own validator node (which requires a minimum of 32 ETH and ongoing infrastructure) or use a liquid staking token (LST) like stETH or rETH. LSTs are smart contracts that pool user deposits and allocate them across node operators who run validators. The LST issues a derivative token representing the staked position.

On Monad, delegation is a single transaction to the staking precompile. The delegator retains direct ownership of their stake, earns rewards from the protocol, and can undelegate and withdraw without depending on any intermediary.

LSTs have pros and cons - they are composable in DeFi and offer instant liquidity by trading on DEXes, but on the other hand, there is additional smart contract risk, and some operational decisions (like parameter management and node operator selection) happen off-chain outside the depositor's control. On Monad, users can choose between direct delegation or LSTs, depending on what they prefer.

Validators and delegation

Validators are the nodes that propose and vote on blocks. Each validator has a commission rate -- the fraction of block rewards it keeps before distributing the remainder to its delegators. Validators set this rate when they register and can change it at any time.

The consensus validator set currently consists of the top 200 validators by total stake (self-stake plus delegated stake), where each active validator must have at least 10,000,000 MON in total stake and at least 100,000 MON in self-delegation. MIP-9 will increase the active set to 300 validators. Validators outside the active set (or below the stake thresholds) are registered but do not participate in consensus and do not earn rewards.

To delegate, a user calls delegate(validator_id) on the staking contract (a precompiled contract at address 0x1000) with MON attached. The delegation is tracked per (validator, delegator address) pair. Wallets like Backpack and staking dashboards like gmonads and MonadVision expose each of the actions described in this article (delegate, compound, claimRewards, undelegate, withdraw) as a button in their UI, so delegators can perform them without calling the staking contract directly.

Epochs and activation timing

The validator set does not change continuously. It is fixed for the duration of an epoch -- 50,000 blocks, or roughly 5.5 hours at 400ms block times. At each epoch boundary, the staking contract takes a snapshot of current stakes and selects the top 200 validators for the next epoch. Within an epoch, the consensus set is frozen: no amount of delegating or undelegating changes who participates in consensus until the next boundary.

This epoch structure means delegations don't take effect immediately. When a user delegates during normal operation, the new stake activates at the next epoch boundary. Until then, the tokens are locked (they leave the delegator's liquid balance) but are not yet earning rewards.

There is an additional subtlety around epoch boundaries. After the boundary block, there is an epoch delay period of 5,000 rounds (~33 minutes) before the new validator set takes effect. Blocks continue to be produced during this window -- consensus does not pause -- but the previous epoch's validator set is still active. Delegations made during this window are deferred further: they activate at the epoch boundary after next, rather than the one currently being processed. This is a precaution to ensure that delegation changes cannot influence a validator set transition that is already underway.

A delegation made early in an epoch will begin earning rewards at the next boundary (~5.5 hours or less). A delegation made after the boundary block (during the epoch delay) will wait until the boundary after that -- up to ~11 hours in the worst case.

How rewards accrue

Validators earn a block reward of 25 MON each time one of their blocks is added. The reward for each block is distributed as follows:

1. The validator takes its commission (commission rate times the block reward).

2. The remainder is distributed to all of the validator's delegators proportionally to their active stake.

Rewards are not pushed to delegators after each block. That would require touching every delegator's state on every block, which doesn't scale. Instead, the staking contract uses an accumulator: a running per-token reward value that increases with each block. When a delegator takes any action (delegate, undelegate, compound, or claim), the contract calculates all rewards owed since the delegator's last action by comparing the current accumulator to the value recorded at the time of that action.

This means rewards accrue silently in the background. A delegator's reward balance grows with every block their validator produces, but no transaction is needed until the delegator decides to do something with those rewards.

Compounding vs. claiming rewards

A delegator has two options for their accrued rewards:

Compound

Calling compound(validator_id) reinvests accrued rewards as additional stake with the same validator. The rewards are added to the delegator's active stake, increasing the base on which future rewards are calculated. No MON is transferred to the delegator's wallet; it all stays in the staking contract as delegated stake.

Compounding has the same activation timing as a new delegation: the compounded rewards follow the epoch activation rules. Until they activate, they are committed but not yet earning further rewards.

Claim

Calling claimRewards(validator_id) withdraws accrued rewards to the delegator's address. The MON is transferred from the staking contract to the delegator's wallet and is immediately liquid. The delegator's staked balance does not change.

In both cases, accrued rewards are calculated at the moment of the call using the accumulator. Any rewards that accrue after the call begin accumulating toward the next compound or claim.

Undelegating and withdrawing

Removing stake is a two-step process with a delay between the steps.

Step 1: undelegate

A delegator calls undelegate(validator_id, amount) to begin unstaking. The requested amount is removed from the delegator's active stake and reserved for withdrawal. Any accrued rewards on the undelegated amount are calculated and credited at this point.

The undelegated tokens enter a cooldown period of 1 epoch (~5.5 hours). During this window, the tokens are no longer earning rewards, but they are not yet available to withdraw. The cooldown exists to ensure that stake which participated in consensus cannot be immediately removed -- this is important for the security of finalized blocks, since validators could otherwise unstake immediately after signing something malicious.

Only active stake can be undelegated. Pending delegations (stake that hasn't yet activated at an epoch boundary) cannot be undelegated until they become active.

Each delegator-validator pair supports up to 256 concurrent withdrawal requests, identified by a withdrawal index (0-255). If undelegating would leave a dust amount (below 1 gwei) of remaining stake, the contract force-undelegates the entire remaining balance to prevent small residual positions from accumulating.

Step 2: withdraw

After the 1-epoch cooldown elapses, the delegator calls withdraw(validator_id, withdrawal_id) to reclaim the tokens. The MON is transferred from the staking contract back to the delegator's wallet and becomes fully liquid.

The two-step process means there is always a gap of roughly 5.5 hours between deciding to unstake and having the tokens available. The delegator should plan around this delay if they need liquidity by a specific time.

Timing summary

Action	When it takes effect
Delegate	Tokens lock immediately; stake activates at next epoch boundary (~5.5 hours max)
Delegate (during epoch delay)	Stake activates at the epoch boundary after next (~11 hours max)
Compound	Same timing as delegate (epoch boundary activation)
Claim rewards	MON arrives in wallet immediately
Undelegate	Stake stops earning immediately; tokens enter 1-epoch cooldown (~5.5 hours)
Withdraw	Available after cooldown elapses

The staking contract

The staking system is implemented as a precompiled contract at address 0x1000. It is not a Solidity contract -- its logic is implemented in C++ as part of the execution engine. This gives it the ability to mint tokens for rewards (increasing total supply), which would not be possible in user-space Solidity.

State changes to the staking contract are triggered by system transactions that the consensus layer injects into blocks: reward distribution after each block, epoch snapshots at epoch boundaries, and epoch transitions at epoch starts. These system transactions are deterministic and verifiable by all nodes, ensuring that staking state is part of the same execution trace as all other on-chain activity.

For developers

The staking precompile is callable from Solidity like any other contract. The Solidity interface and ABI JSON are available in the reference docs.

Monad Foundry, a fork of Foundry with built-in support for Monad's precompiles, allows developers to test staking interactions locally -- including delegating, undelegating, claiming rewards, and epoch transitions -- without deploying to a live network.

Originally published on X on April 24, 2026.