The Stake Allocation Formula

Every epoch, shMonad calculates how much stake each validator should receive using a mathematical formula. This page explains what that formula does and why it works.

The Core Principle

The allocation system follows two fundamental rules: validators should increase their stake proportional to their contribution to total protocol revenue and decrease their stake proportional to their existing share of the total staked assets.

If Validator A earned 10% of all revenue, they should receive approximately 10% of new stake allocations. If Validator B earned 30%, they should receive approximately 30% of new stake allocations.

This proportional allocation ensures:

• High-performing validators naturally receive more resources
• Poor performers lose stake over time
• The protocol maximizes returns for shMON holders
• No single validator can dominate without earning it

The Formula in Detail

For Increasing Stake (New Deposits)

When new MON is deposited and needs to be staked, each validator receives:

$$\text{Stake Increase} = \text{Total New Stake} \times \frac{\text{Validator's Smoothed Revenue}}{\text{All Validators' Smoothed Revenue}}$$

Breaking this down:

• Total New Stake: All the MON that needs to be delegated this epoch, such as new deposits and recently-earned revenue
• Validator's Smoothed Revenue: The validator's average earnings over recent epochs
• All Validators' Smoothed Revenue: Sum of all validators' smoothed revenue

The fraction represents the validator's share of total protocol earnings. Multiply that share by the total amount to allocate, and you get each validator's allocation.

Example:

• Total new stake to allocate: 1,000 MON
• Validator A smoothed revenue: 50 MON
• Total smoothed revenue across all validators: 500 MON
• Validator A's share: 50 / 500 = 10%
• Validator A receives: 1,000 × 0.10 = 100 MON

For Decreasing Stake (Withdrawals)

When users withdraw and MON needs to be unstaked, each validator loses stake proportional to how much they currently have available:

$$\text{Stake Decrease} = \text{Total Withdrawal Amount} \times \frac{\text{Validator's Available Stake}}{\text{All Validators' Available Stake}}$$

Why "available stake"?

Not all staked MON can be immediately withdrawn. Some might be:

• Recently staked and still in a queue
• Already in the process of being unstaked
• Otherwise locked temporarily

The formula only considers stake that can actually be withdrawn right now.

The intuition is that when users need their MON back, the protocol proportionally pulls from each validator based on how much they have available. This distributes the withdrawal burden fairly across all validators rather than hitting any single validator disproportionately.

Balancing Flows

Most epochs have both deposits (new stake arriving) and withdrawals (unstake requests to fulfill). The net effect determines each validator's final change:

$$\text{Net Change} = \text{Stake Increase} - \text{Stake Decrease}$$

• If Stake Increase > Stake Decrease: Validator receives more stake
• If Stake Decrease > Stake Increase: Validator loses stake
• If they're equal: Validator's stake stays roughly the same

Minimum Thresholds

To avoid tiny inefficient transactions, the protocol sets a minimum threshold (a "dust limit"). If a calculated change is below this threshold, it's either:

• Rolled into the next epoch's allocation
• Redistributed among other validators
• Added back to the queue for future allocation

This prevents the protocol from spending gas on moving insignificant amounts between validators.

Special Cases

Joining Validators

When a validator is first added:

• They start with zero stake
• In their first active epoch, they receive allocation based on any revenue they've earned
• If they haven't earned revenue yet, they receive no allocation
• • Once a validator has stake, that stake's rewards count as revenue for the next epoch
• • Brand new validators have no stake and therefore have no revenue from staking rewards
• • The best way for a validator to overcome the "revenue cold start problem" is to integrate FastLane's MEV protocol
• Future epochs treat them normally based on their performance

Exiting Validators

When a validator is being removed:

• They stop receiving new allocations
• Their existing stake begins unstaking
• The unstaking follows normal epoch timing
• Once fully unstaked, they're completely removed

Inactive Validators

If a validator is temporarily inactive (not producing blocks):

• Their revenue drops to zero
• Smoothed revenue gradually decreases over epochs
• Allocation weight diminishes
• Stake slowly migrates to active validators

This automatic response means shMonad doesn't need manual intervention to handle validator issues—the formula naturally reallocates toward performing validators.

Why This Formula Works

The allocation formula achieves several goals simultaneously:

1. Performance-based: Better validators get more resources
2. Automatic: No governance or manual decisions required
3. Fair: Proportional to actual contribution, not politics
4. Efficient: Doesn't over-rebalance on small variations
5. Robust: Handles validators entering, exiting, or having issues

By tying allocations directly to measured performance (smoothed revenue), the formula creates a self-correcting system that aligns validator incentives with protocol returns.

The underlying principle is proportional allocation: validators that generate more revenue receive proportionally more stake. This creates a natural incentive structure where stake flows toward higher-performing validators.