Skip to main content
The Revenue module provides a comprehensive system for compensating validators based on their performance. This module operates alongside the traditional staking rewards, offering additional incentives tied directly to metrics that measure validator reliability and service quality.

Rewards System Architecture

The Revenue module’s primary responsibility is to assess validator performance, calculate appropriate compensation, and distribute rewards according to configurable schedules. The system leverages real-time performance data and price information to ensure fair and timely compensation. The Revenue module operates through a continuous cycle of performance monitoring, assessment, and reward distribution. During each block, the system updates reward asset prices, processes validator participation data, and checks whether it’s time to distribute payments based on the configured schedule.

Performance Assessment

Validators are evaluated on two critical metrics:
  1. Block Production Participation: The percentage of blocks signed during the payment period
  2. Oracle Price Submissions: The percentage of oracle votes provided during the payment period

Performance Requirements

The module uses two configurable thresholds to determine reward eligibility:
  • Required At Least: The minimum performance required on both metrics to qualify for any rewards
  • Allowed To Miss: The maximum percentage of misses allowed to still receive full rewards

Performance Rating Breakdown

The performance rating system has three zones based on validator performance: Zone 1: No Rewards (0.0 rating)
  • If either block participation OR oracle participation falls below the “required at least” threshold
  • Example: If required_at_least = 90%, and validator signs only 88% of blocks → 0.0 rating (no rewards)
Zone 2: Partial Rewards (0.0-1.0 rating)
  • Performance falls between “required at least” and “allowed to miss” thresholds
  • Rating calculated using quadratic formula: 0.5 * ((1 - missedBlocksPerfQuo²) + (1 - missedOracleVotesPerfQuo²))
  • The quadratic curve provides gentler penalties for validators near the “allowed to miss” threshold
Zone 3: Full Rewards (1.0 rating)
  • Both block participation AND oracle participation meet or exceed the “allowed to miss” threshold
  • Example: If allowed_to_miss = 5%, and validator misses only 3% of blocks and 2% of oracle votes → 1.0 rating (full rewards)
Example with real thresholds:
  • required_at_least = 90% (must sign at least 90% to get any rewards)
  • allowed_to_miss = 5% (can miss up to 5% and still get full rewards)
  • Partial reward zone: 90-95% performance

Calculation of Performance Quotients

Both missedBlocksPerfQuo and missedOracleVotesPerfQuo are calculated using the same algorithm. The module uses the calCMissedPerfQuo function to determine how much a validator’s performance falls within the partial performance range:
// calCMissedPerfQuo calculates the negative coefficient based on the missed share, allowed to miss,
// and performance threshold. If the missed share is LTE allowed to miss, the returned value is
// 0.0, i.e. no negative coefficient for this criteria.
func calCMissedPerfQuo(
	missedShare math.LegacyDec,
	allowedToMiss math.LegacyDec,
	perfThreshold math.LegacyDec,
) math.LegacyDec {
	if missedShare.LTE(allowedToMiss) {
		return math.LegacyZeroDec()
	}

	finedMissedShare := missedShare.Sub(allowedToMiss)    // how much missed over the allowed value
	perfEvalWindow := perfThreshold.Sub(allowedToMiss)    // span of evaluation window
	missedPerfQuo := finedMissedShare.Quo(perfEvalWindow) // how much missed in the evaluation window

	return missedPerfQuo
}
Calculation Steps:
  1. Check Full Performance: If missedShare <= allowedToMiss, return 0.0 (no penalty, full rewards)
  2. Calculate Excess Misses: finedMissedShare = missedShare - allowedToMiss (how much over the allowed threshold)
  3. Calculate Evaluation Window: perfEvalWindow = perfThreshold - allowedToMiss (the range for partial performance)
  4. Calculate Performance Quotient: missedPerfQuo = finedMissedShare / perfEvalWindow (normalized position within partial range)
This function returns a value between 0.0 and 1.0, where:
  • 0.0 = performance at the “allowed to miss” threshold (full rewards)
  • 1.0 = performance at the “required at least” threshold (no rewards)
This quadratic approach provides a smoother penalty curve that more gently penalizes validators who miss just a few more blocks than the “allowed to miss” threshold.

Payment Scheduling

The module supports multiple payment schedule types:
  1. Monthly: Rewards are distributed at the beginning of each calendar month
  2. Block-Based: Rewards are distributed after a specified number of blocks
  3. Empty: No rewards are distributed (used for testing or disabling payments)
The payment schedule is stored in two components:
  • The schedule type in the module parameters (controllable by governance)
  • The schedule state in the module’s store (updated automatically)
When a payment period ends, the module:
  1. Calculates each validator’s performance rating
  2. Determines the reward amount in the reward asset
  3. Transfers rewards to eligible validators
  4. Resets performance metrics for the new period

Price Calculation

Rewards are defined in USD terms but paid in the token specified in module parameters. To accurately convert between USD and token amounts, the module:
  1. Tracks the cumulative price of the reward asset in each block
  2. Calculates the Time-Weighted Average Price (TWAP) over a configurable window
  3. Uses this TWAP to determine the exact token amount equivalent to the USD reward
The TWAP calculation follows:
TWAP = (CumulativePrice_now - CumulativePrice_window_start) / (Timestamp_now - Timestamp_window_start)

Treasury Management

The Revenue module maintains a treasury account that holds funds for validator compensation. This treasury:
  1. Receives funds through the FundTreasury message
  2. Automatically pays validators at the end of each payment period
  3. Can be managed through governance decisions
The treasury ensures there’s a sustainable and dedicated source of funds for validator compensation independent of regular inflationary staking rewards.
I