Skip to main content

Revenue Sources and Tracking

shMonad tracks validator revenue across multiple epochs to make fair allocation decisions. Understanding how revenue is measured helps explain why stake flows to certain validators.

Two Allocation Revenue Buckets​

Validators can earn revenue in two ways:

1. Staking Yield​

These are the standard block rewards that Monad validators earn for participating in consensus. When a validator produces blocks or attests correctly, they receive MON as a reward.

How shMonad sees it: The protocol queries each validator's earned rewards through Monad's staking system, collecting any accumulated rewards at epoch boundaries.

After fees: The protocol takes a 5% staking rewards commission, and the remaining 95% increases the equity backing all shMON tokens.

For allocation, v1.2 applies a staking-yield deadband. The protocol estimates how much staking yield a validator should have earned based on its signal stake, then filters out a configurable percentage of that expected yield. The default deadband is 8,000 bps, meaning 80% of expected stake-proportional yield is ignored for allocation scoring.

This prevents validators from keeping stake merely because they already had stake. Yield above the expected floor still counts.

2. Non-Staking Revenue​

Validators may also receive additional payments from:

  • MEV (Maximum Extractable Value) from validator-aligned transaction ordering
  • ACE (Application-Controlled Execution) a form of application-aligned MEV protection
  • Other value capture mechanisms from FastLane-operated infrastructure and smart contracts

These payments arrive as MON transfers. The protocol recognizes them, allocates a share to the validator, applies the boost yield commission (currently 50% on mainnet), and distributes the remainder to increase shMON value. See Parameters and Fees for the current fee split.

For allocation, non-staking revenue is multiplied by a configurable multiplier. The v1.2 default is 2x, bounded between 1x and 20x. This gives more allocation weight to revenue streams that are less mechanically tied to existing stake.

Multi-Epoch Revenue Tracking​

The allocation system doesn't just look at the most recent epoch -it tracks revenue across multiple epochs and smooths the data.

The Importance of Smoothing​

Without smoothing, a validator who gets lucky in one epoch (perhaps they produced several high-value blocks) would receive a disproportionate allocation increase. Then, in the next epoch, their allocation would drop dramatically.

This creates inefficiency:

  • Constantly moving large amounts of stake between validators
  • Higher transaction costs from frequent rebalancing
  • Unstable validator revenues
  • Potentially worse performance as validators can't rely on stable stake

How Smoothing Works​

Instead of using only the most recent epoch's revenue, the system averages across multiple epochs:

Smoothed Bucket=Bucketlast epoch+Buckettwo epochs ago2\text{Smoothed Bucket} = \frac{\text{Bucket}_{\text{last epoch}} + \text{Bucket}_{\text{two epochs ago}}}{2}

This two-epoch moving average:

  • Reduces impact of random variation
  • Makes allocations more stable
  • Gives validators predictable stake levels
  • Still responds to genuine performance changes

The Effect on Allocations​

Example scenario:

Validator A consistently earns 100 MON per epoch.
Validator B typically earns 100 MON but had one lucky epoch earning 200 MON.

Without smoothing:

  • In the lucky epoch, Validator B would receive a huge allocation increase
  • The next epoch, that allocation would drop back down

With smoothing:

  • In the lucky epoch, Validator B's smoothed bucket value = (200 + 100) / 2 = 150
  • The next epoch, if they earn 100, smoothed bucket value = (100 + 200) / 2 = 150
  • Two epochs later, assuming normal 100 earnings, = (100 + 100) / 2 = 100

The same smoothing happens independently for staking-yield and non-staking revenue buckets, producing gradual adjustments rather than violent swings.

Revenue Attribution​

Not all revenue is treated equally for allocation purposes:

Registered validators: Validators explicitly registered with shMonad have their revenue tracked individually and used for allocation calculations.

Unregistered validators: If an unregistered validator somehow receives rewards that pass through shMonad (rare but possible), that revenue benefits all shMON holders but doesn't affect allocation weights.

Why the distinction: The protocol can only measure and respond to performance from validators it knows about. Unregistered validator revenue becomes a general boost to returns rather than an allocation signal.

Isolated stake: Isolated rewards remain economically isolated. Governance may choose whether validator-attributed isolated rewards are included in the allocation signal, but including them affects only the signal. It does not move isolated value into pooled shMON equity.

Higher weighted revenue leads to higher allocation weight, which leads to more stake delegated.

This creates a natural feedback loop:

  1. Validators that perform well earn more revenue
  2. More revenue leads to higher allocation weights
  3. Higher weights mean more stake from shMonad
  4. More stake enables more blocks and more revenue (reinforcing good performance)

Conversely, underperforming validators naturally receive less stake over time. This automatic performance-based rebalancing happens every epoch without any manual intervention, ensuring shMonad's stake flows toward validators that maximize returns for all holders.