Validator Rewards

x/valrewards awards validators using per-epoch points. Rewards are not share-based: each validator listed in the previous block’s commit info earns points in proportion to its voting power (whether or not it signed), proposers receive a fixed bonus, and epoch rewards are allocated proportionally to points. The module pays validators only; delegators receive no x/valrewards rewards.

Runtime model

current_reward_settings are used for the epoch currently accumulating points.
next_reward_settings are staged values that become active at the next epoch boundary.
Changes made during epoch N do not alter calculations already in progress for epoch N.
Whitelisted accounts can submit runtime setter messages.
Whitelist changes are governance-only through MsgUpdateParams.
PROPOSER_BONUS_POINTS remains hardcoded and is currently 1.

If rewarding_paused is switched to true during an epoch, the current epoch still completes and pays normally. The next epoch starts paused, records no new validator points, and creates no new outstanding reward rows.

Core logic

Area	Behavior
Points	Every validator listed in the previous block’s commit info receives points proportional to voting power, whether it signed, was absent, or voted nil; proposer receives a fixed bonus.
Epoch rewards	At epoch end, total points split configured `rewards_per_epoch` across validators.
Claiming	Claims are one-time and single-validator. Outstanding rewards are zeroed after success.
Sponsor calls	Cosmos msg and EVM precompile claim paths are sponsor-callable; payout always goes to the target validator operator.
Funding	Claims are paid from the module rewards pool and fail if the pool has insufficient balance.
Epoch transitions	Payout uses completed epoch settings; only after payout are next settings promoted to current settings.

Mainnet values

On mainnet (c8ntinuum_8-1) the epoch length, reward per epoch, and whitelist differ from the default genesis below, and the rewards pool was funded at genesis:

Setting	Mainnet value
`blocks_in_epoch` (current and next)	`21600`
`rewards_per_epoch` (current and next)	`45000000000000000000000` (45,000 CTM)
`rewarding_paused`	`false`
`params.whitelist`	Three team-controlled operator accounts
Rewards pool funded at genesis	`16425000000000000000000000ctm` (16,425,000 CTM)

The whitelisted accounts can change blocks_in_epoch, rewards_per_epoch, and rewarding_paused without a governance proposal. Their changes are staged in next_reward_settings and take effect at the next epoch boundary. To see the current values, run ctmd query valrewards params and ctmd query valrewards rewards-pool.

Default genesis

These are the module defaults for a newly generated genesis, not the mainnet values.

{
  "valrewards": {
    "params": {
      "whitelist": []
    },
    "current_reward_settings": {
      "blocks_in_epoch": 17280,
      "rewards_per_epoch": "45004521205479450000000",
      "rewarding_paused": false
    },
    "next_reward_settings": {
      "blocks_in_epoch": 17280,
      "rewards_per_epoch": "45004521205479450000000",
      "rewarding_paused": false
    },
    "epoch_state": {
      "current_epoch": 0,
      "blocks_into_current_epoch": 0
    },
    "epoch_to_pay": 0,
    "validator_points": [],
    "validator_outstanding_rewards": []
  }
}

The rewards pool balance is not duplicated inside app_state.valrewards; it remains part of the module account balance in auth/bank state.

Validation rules

Field	Rule
`blocks_in_epoch`	`int64`, minimum `20`, maximum `6500000`
`rewards_per_epoch`	Required decimal integer string, minimum `1000000000000000000`, maximum `25000000000000000000000000`
`rewarding_paused`	Boolean
`params.whitelist`	Valid bech32 account addresses only; duplicates rejected
Deposit amount	Valid positive coin amount
Outstanding rewards	Must use `evmtypes.DefaultEVMDenom`; sum cannot exceed the funded module account balance
`epoch_to_pay`	Cannot exceed `epoch_state.current_epoch`
Points/rewards entry epochs	Cannot exceed `epoch_state.current_epoch`

Exposed methods

Cosmos SDK messages

MsgDepositRewardsPool(depositor, amount)
MsgClaimRewards(validator_operator, epoch, requester)
MsgSetBlocksInEpoch(signer, blocks_in_epoch)
MsgSetRewardsPerEpoch(signer, rewards_per_epoch)
MsgSetRewardingPaused(signer, rewarding_paused)
MsgUpdateParams(authority, params)

MsgClaimRewards is sponsor-callable: any valid requester may submit the transaction, but rewards are still paid only to the target validator account. Runtime setter messages require the signer to be present in params.whitelist; MsgUpdateParams is authority-only and intended for governance.

Queries

Query/RewardsPool
Query/ValidatorOutstandingRewards
Query/DelegationRewards
Query/Params

Query/ValidatorOutstandingRewards expects a canonical Bech32 validator operator address. Hex 0x... addresses are rejected. Query/DelegationRewards does not return delegator rewards. Its delegator field must be a validator operator’s account address (the c8... or 0x... account that owns the c8valoper... address). It returns that validator’s own outstanding reward for the epoch, the same value as Query/ValidatorOutstandingRewards, and fails with target address must be a validator operator for any other address.

EVM precompile

Address: 0x0000000000000000000000000000000000000714

rewardsPool()
validatorOutstandingRewards(epoch, validatorAddress)
delegationRewards(delegatorAddress, epoch) (delegatorAddress must be a validator operator’s account; see Query/DelegationRewards above)
depositValidatorRewardsPool(depositor, amount)
claimRewards(validatorOperatorAddress, epoch)

For exact ABI signatures, see Precompile ABI Reference.

CLI

ctmd query valrewards rewards-pool
ctmd query valrewards validator-outstanding-rewards <epoch> <c8valoper...>
ctmd query valrewards delegation-rewards <validator-operator-account> <epoch>
ctmd query valrewards params

ctmd tx valrewards deposit <amount>
ctmd tx valrewards claim <validator-operator-account> <epoch>
ctmd tx valrewards set-blocks-in-epoch <blocks-in-epoch>
ctmd tx valrewards set-rewards-per-epoch <rewards-per-epoch>
ctmd tx valrewards set-rewarding-paused <true|false>

claim and delegation-rewards take the validator operator’s account address (c8... or 0x...), for example the output of ctmd keys show <operator-key> -a, not the c8valoper... form. validator-outstanding-rewards takes the c8valoper... form.

Learn

Core Concepts

Chain Architecture

Execution and EVM

Interoperability and IBC

Modules & Precompiles

Transaction Lifecycle

Runtime model

Core logic

Mainnet values

Default genesis

Validation rules

Exposed methods

Cosmos SDK messages

Queries

EVM precompile

CLI

​Runtime model

​Core logic

​Mainnet values

​Default genesis

​Validation rules

​Exposed methods

​Cosmos SDK messages

​Queries

​EVM precompile

​CLI

Runtime model

Core logic

Mainnet values

Default genesis

Validation rules

Exposed methods

Cosmos SDK messages

Queries

EVM precompile

CLI