Skip to main content

Additional Allocation Mechanics

Beyond the core allocation formula, several other mechanisms help shMonad manage stake effectively across all conditions.

Incentive Alignment Through Turnover​

Even when deposits and withdrawals perfectly balance (net flow is zero), the protocol intentionally creates a small amount of "turnover"—unstaking from some validators and restaking with others.

Rationale for turnover:

Without turnover, a validator that once had high stake could maintain that allocation indefinitely, even if their performance declines. By forcing periodic reallocation, the system:

  • Continuously tests validators against current performance
  • Prevents stale allocations from persisting
  • Ensures stake flows toward currently-best-performing validators
  • Maintains competitive pressure on all validators

How it works:

Even with zero net flow, the protocol unstakes a small percentage of total stake and reallocates it based on current performance weights. This percentage is configurable but typically quite small (a few percent) to balance optimization benefits against rebalancing costs.

The effect: Over several epochs, underperforming validators gradually lose stake while improving validators gain it, even during periods of stable total deposits.

Handling Capacity Constraints​

Sometimes the system can't immediately execute all planned allocations due to liquidity constraints.

Staking Queue Capacity​

New stake can only be allocated if there's sufficient liquid MON available. If withdrawal requests temporarily drain liquid reserves:

  • Planned stake increases are delayed
  • The amounts roll into the next epoch's allocation queue
  • Once liquidity recovers, queued stake gets allocated
  • Priority goes to oldest queued amounts

Unstaking Queue Capacity​

Similarly, not all staked MON can be unstaked simultaneously. If:

  • More withdrawals are requested than currently unstakable MON
  • The amounts roll forward to the next epoch
  • As previously-initiated unstakes complete, capacity frees up
  • Queued unstakes process in order

The result: During extreme conditions (large withdrawals paired with most stake being recently added), there may be temporary delays. But the queuing system ensures all requests eventually process fairly.

Atomic Pool Integration​

The atomic unstaking pool affects stake allocation in subtle ways:

Target liquidity: The protocol maintains a target percentage of equity as instant-withdrawal liquidity. This MON:

  • Is not staked with validators
  • Reduces the amount available for delegation
  • Adjusts epoch-by-epoch based on equity changes

Revenue offset: When protocol revenue arrives, it can offset atomic pool utilization before being allocated to validators. This means:

  • Some revenue may not flow to staking immediately
  • The atomic pool "borrows" from revenue to maintain liquidity
  • Once utilization normalizes, revenue flows to staking as normal

This integration ensures instant withdrawals remain available without significantly impacting long-term staking returns.

Edge Cases and Safety Mechanisms​

The allocation system includes several safeguards:

Minimum Validator Deposit​

Validators must receive at least a minimum amount (typically 1 MON) per allocation. Below this threshold:

  • The allocation is skipped
  • The amount returns to the queue for next epoch
  • This prevents dust allocations that waste gas

Verification Checks​

After each epoch, the protocol verifies:

  • Expected staked amounts match actual amounts per validator
  • No stake has gone missing
  • All pending operations are properly tracked

If discrepancies appear, the system emits warning events so any issues can be investigated and resolved.

Slashing Protection​

If Monad implements slashing in the future (currently not active), shMonad includes a circuit breaker:

  • If any validator's stake drops unexpectedly by a large percentage
  • And the loss exceeds a threshold percentage of total equity
  • The protocol can freeze operations temporarily
  • This prevents cascading issues while the situation is assessed

This is a safety mechanism not expected to trigger under normal operation. If activated, it pauses minting shMON, redeeming shMON, delegating stake and undelegating stake. Importantly, the trading and transferring of shMON would continue undisrupted.

Continuous Improvement​

One of the benefits of on-chain allocation is that improvements can be made over time:

  • Allocation formulas can be refined based on observed behavior
  • Parameters (like turnover percentage or smoothing periods) can be adjusted
  • New mechanisms can be added to handle edge cases
  • All changes are transparent and verifiable

The objective is a self-optimizing system that balances returns against operational overhead and risk. By handling these mechanics automatically, the protocol abstracts away internal complexity from end users.