Claiming rewards

Draft page

For the deep cast-based how-to (with hardware-wallet and keystore variants), see Claiming rewards in Advanced operations.

This page explains where Aztec rewards live, what determines who gets them, and the confusions that make operators think their rewards are missing.

TL;DR

• Rewards accrue on the Rollup contract under your coinbase address. Nothing reaches your wallet until you call claimSequencerRewards(coinbase).
• You earn roughly 350 AZTEC per checkpoint you propose (70% of the 500 AZTEC checkpoint reward).
• After a rollup upgrade, your old rewards stay on the old Rollup contract. The staking dashboard handles this for you, or you can claim from each contract manually.
• Slashing reduces your stake, not your accrued rewards.

Where rewards live

Your sequencer's rewards accumulate on the Rollup contract, indexed by your coinbase address. They are not auto-distributed; calling claimSequencerRewards(coinbase) releases them.

Role	What it does	Configured where
Coinbase	L1 address that receives the rewards	Your node's keystore (coinbase field), per attester
Publisher	Account that pays L1 gas to claim	Anyone can pay the gas; the funds still go to the coinbase
Withdrawer	Not involved in reward claiming	(Relevant only for stake withdrawal; see Identity model)

When rewards show up

Rewards are credited to your coinbase after the epoch containing your proposed checkpoint has been proven, not at proposal time. Proving happens within the proof submission window (typically a few epochs after the block).

Practical timing: most rewards land within 1 to 2 hours of the corresponding block. During gas-spike periods or proving incidents, the lag can extend. If an epoch is pruned (provers missed the window), the rewards for that epoch do not credit at all.

How much you earn

Read from the Rollup contract's getRewardConfig():

• Checkpoint reward: 500 AZTEC
• Sequencer share: 7000 BPS (70%)
• Per proposed checkpoint: roughly 350 AZTEC to your coinbase

The remaining 30% routes to two reward distributors configured in the same struct. The split can change by governance proposal.

How to check pending rewards (without claiming)

You can query the contract without spending gas:

cast call $ROLLUP_ADDRESS \
  "getSequencerRewards(address)(uint256)" \
  $COINBASE_ADDRESS \
  --rpc-url $RPC_URL

The result is in wei. Divide by 10^18 for the human-readable AZTEC amount.

For a step-by-step including the cast install + RPC setup, see the detailed claim guide.

The multi-rollup case that bites operators

This is the most common "where are my rewards?" confusion.

When the Aztec network does a major rollup upgrade (v2 → v4 Alpha happened in 2026-03; V5 is upcoming in mid-2026), a new Rollup contract is deployed and made canonical. The old Rollup contract still exists with code; it still holds the rewards you earned before the upgrade.

Symptom: after a rollup upgrade, your staking-dashboard pending-rewards balance drops. Rewards from before the upgrade are not lost; they sit on the prior Rollup contract.

Solutions, in order of ease:

1. Use the staking dashboard. stake.aztec.network shows pending rewards across every rollup the Registry has ever made canonical and routes claims through a single transaction cart. This is the recommended path.
2. Claim directly via cast. Call claimSequencerRewards(coinbase) against the old Rollup contract's address, separately from your canonical-rollup claim. The function exists on both contracts.

The two canonical rollup addresses on mainnet:

Rollup	Address
Current canonical	0xae2001f7e21d5ecabf6234e9fdd1e76f50f74962
Previous (v0)	0x603bb2c05d474794ea97805e8de69bccfb3bca12

Both currently return isRewardsClaimable() = true, so rewards on the previous rollup are claimable.

The reward gate

The Rollup contract has an isRewardsClaimable() flag set by governance. When false, claimSequencerRewards reverts. Check before assuming:

cast call $ROLLUP_ADDRESS "isRewardsClaimable()(bool)" --rpc-url $RPC_URL

Provider commission flow

If you operate as a staking provider, the reward path is different.

Rewards from your sequencers route into a Splits contract (one per delegation) that holds the split between you and your delegators. Your commission (a percentage you set on the provider record) routes automatically to your providerRewardsRecipient address; the remainder is claimable by each delegator.

The Operator Tools tab on stake.aztec.network bundles claim, distribute, and withdraw for all your delegations into one multicall. For day-to-day operation that is the path; manual cast commands work but are tedious at scale.

Commission rates are stored on the StakingRegistry contract (0x042df8f42790d6943f41c25c2132400fd727f452) and are updated by the provider admin via updateProviderTakeRate.

What if my rewards disappeared after a slash?

Slashing reduces your stake, not your pending rewards. Rewards already accrued to your coinbase are unaffected by slashing events; they are accounting entries on the Rollup contract, separate from your staked balance in the GSE. You can still claim them.

If you have been ejected (stake fell below the local 190,000 AZTEC threshold), you stop earning new rewards on subsequent epochs but the rewards you have already accrued are still claimable.

See also

• Detailed claim guide: cast recipes including hardware-wallet variant
• Identity model: what the coinbase, publisher, and withdrawer addresses each do
• Slashing: what happens to your stake (not your rewards) when offenses occur
• Operator tooling: the staking dashboard handles multi-rollup claims with no cast required