Reward Manager
How the Reward Manager calculates and distributes staking rewards
The Reward Manager is an optional Subnet-EVM precompile at 0x0200000000000000000000000000000000000004. It sets where the L1 sends transaction fees: to a reward address (setRewardAddress), to the block producer (allowFeeRecipients), or to the burn address (disableRewards). It does not calculate or pay staking rewards. On a permissionless L1, the staking manager contract calculates staking rewards with its reward calculator contract, and the Native Minter precompile mints them.
Without the Reward Manager, the staking manager still pays staking rewards. The L1 burns transaction fees by default. If the genesis chain config sets allowFeeRecipients, each block producer gets the fees of its blocks at the feeRecipient address in its node config. Enable the Reward Manager to send fees to one reward address, or to change the fee destination after the chain starts.
How the Reward Manager Works
The P-Chain does not pay staking rewards to L1 validators. The proposal-commit/abort mechanism below applies only to Primary Network validators and delegators. This page shows it for comparison. On a permissionless L1, the staking manager contract calculates and pays rewards on the L1.
Reward Calculation
When the P-Chain adds a Primary Network validator or delegator, it calculates the potential reward with reward.Calculator and adds it to the current supply. At the end of the staking period, the P-Chain pays this reward (commit) or removes it from the supply (abort). The calculation uses:
- Staking Duration: How long tokens were staked
- Stake Amount: The staker's own stake. A validator's reward does not count the stake of its delegators. Each delegator gets a separate reward.
- Current Supply: The total token supply affects reward rate
- Network Parameters: Configured reward rates and caps
The calculation follows this general formula:
remaining_supply = supply_cap - current_supply
minting_rate = min_rate + (max_rate - min_rate) × duration / minting_period
reward = remaining_supply × (stake / current_supply) × minting_rate × (duration / minting_period)
# Mainnet: supply_cap = 720,000,000 AVAX, max_rate = 12%, minting_period = 365 days.
# min_rate is 10% for stakes that started before Helicon. For later stakes it falls linearly to 7.5% over the 90 days after Helicon (ACP-285).The reward rate typically decreases as supply increases, creating controlled inflation.
Reward Distribution Process
1. Block Building
When a staker's end time is reached, the Block Builder creates a RewardValidatorTx transaction. This transaction proposes to:
- Remove the validator/delegator from the active set
- Calculate their earned rewards
- Return their stake plus rewards
2. Execution Phase
The RewardValidatorTx is executed as a proposal transaction by the Proposal Executor:
- The Reward Calculator computes the potential reward amount
- The P-Chain State is queried for staker information
- A reward UTXO is prepared (if reward > 0)
3. Commit or Abort
The transaction can follow two paths:
Commit Path (Normal Operation)
- Validator receives: Original stake + validation rewards
- Delegators receive: Their share of rewards (minus delegation fees)
- Delegation fees are either:
- Post-Cortina: Accumulated for the validator to claim later
- Pre-Cortina: Paid immediately to the validator
Abort Path (Uptime Below the Requirement)
- Validator receives: Only their original stake (no rewards)
- Potential rewards are burned (supply decreased)
- Accumulated delegation fees are still returned
- Each node prefers abort when it measures the validator's uptime below the requirement: at least 90% for validations that start at or after Helicon (ACP-267), at least 80% for earlier validations
Is this guide helpful?


