Introducing the Flush Rewarder: Incentivizing Validator Set Maintenance

What is the Flush Rewarder?

The Flush Rewarder is a simple but important piece of infrastructure that incentivizes actors on Ethereum L1 to maintain Aztec’s validator set. When new validators stake and join the entry queue, someone needs to “flush” them into the active attester set. The Flush Rewarder pays AZTEC tokens to anyone who performs this service.

Why Does It Exist?

Aztec’s rollup uses a validator set that requires periodic maintenance. When new validators deposit their stake, they enter a queue rather than immediately becoming active. This queue needs to be “flushed” to move pending validators into the active set.

Rather than relying on a centralized operator or hoping someone does this out of goodwill, the Aztec Network employs economic incentives. The Flush Rewarder ensures this housekeeping task gets done reliably by rewarding those who do it.

How It Works

The contract is straightforward:

  1. flushEntryQueue() - The main function anyone can call. It triggers the rollup to process pending validators and tracks how many were actually inserted.

  2. claimRewards() - After accumulating rewards, callers can claim their earned AZTEC tokens.

  3. rewardsOf(address) - Check how much unclaimed AZTEC an address has earned.

  4. rewardsAvailable() - View how much AZTEC remains in the reward pool.

Contract Interactions

The Flush Rewarder interacts directly with the Aztec Rollup contract:

Caller → FlushRewarder.flushEntryQueue() → Rollup.flushEntryQueue()

When called, it:

  1. Records the current active attester count
  2. Calls ROLLUP.flushEntryQueue() to process the entry queue
  3. Calculates how many new validators were inserted
  4. Credits the caller with insertions × rewardPerInsertion AZTEC

Funding and Governance

The Flush Rewarder is owned by the Aztec Governance contract, which also controls the CoinIssuer contract, the only contract authorized to mint new AZTEC tokens. When the reward pool runs low, Governance can mint additional AZTEC tokens to fund the Flush Rewarder. Like all governance actions, this requires a governance vote to ratify the proposal.

Governance can also adjust the rewardPerInsertion rate as market conditions change. As the AZTEC/ETH price fluctuates and Ethereum gas costs vary, the reward rate may need tuning to keep flushing economically viable for participants. This flexibility ensures the incentive mechanism remains effective over time.

The Reward: 100 AZTEC Per Insertion

The current reward rate is 100 AZTEC per validator inserted.

Example: Alice calls flushEntryQueue(). The rollup processes 1 pending validator into the active set. Alice earns 100 AZTEC. She can later call claimRewards() to withdraw her tokens.

Fully Permissionless

Anyone can call flushEntryQueue(). There’s no whitelist, no KYC, no approval needed. If there are validators in the queue and rewards available, actors earn AZTEC for flushing the queue.

This creates a natural market: callers weigh their gas costs against expected AZTEC rewards and decide whether to participate.

Rate Limiting: How Many Validators Can Be Flushed?

The flush mechanism has built-in rate limiting to ensure controlled validator set growth.

Current Live Configuration:

Parameter Value
normalFlushSizeMin 1
normalFlushSizeQuotient 2048
maxQueueFlushSize 8
Epoch length ~38.4 minutes

The Formula:
validatorsPerEpoch = min(max(activeAttesters / quotient, min), max)

Current Reality (with ~1,927 active attesters):

  • 1927 / 2048 = 0, so it falls back to the minimum of 1 validator per epoch
  • With epochs lasting ~38 minutes, that’s roughly 37-38 validators per day maximum

What This Means for Flushers:

  • You can call flushEntryQueue() as often as you want, but you’ll only earn rewards when there’s a validator to flush
  • Once a validator is flushed in an epoch, additional calls will succeed but process zero validators
  • The reward opportunity resets every ~38 minutes with each new epoch

Pending Governance Proposal

There is currently a governance proposal to update the staking queue configuration:

Parameter Current Proposed
normalFlushSizeMin 1 1
normalFlushSizeQuotient 2048 400
maxQueueFlushSize 8 4

Impact of the Proposed Changes:

With ~1,927 active attesters and the new quotient of 400:

  • 1927 / 400 = 4, which equals the new max of 4 validators per epoch
  • This would increase throughput from ~38 to ~150 validators per day

The lower maxQueueFlushSize (8 → 4) caps the maximum even as the validator set grows, but the significantly lower quotient (2048 → 400) means this cap will be reached much sooner.

Growth Trajectory Under Proposed Config:

Active Attesters Validators per Epoch Per Day (~37.5 epochs)
<400 1 ~38
800 2 ~75
1,200 3 ~112
1,600+ 4 (max) ~150

Early Adopters: Stats as of January 6th

Since deployment, only two addresses have been actively calling the Flush Rewarder:

Address Gas Spent Total Txs Successful Txs AZTEC Earned Cost per AZTEC Earned
0x0881...2d18 0.131602 ETH 1,378 1,378 137,800 0.00000096 ETH ($0.0031)
0x2490...d8c8 0.103840 ETH 795 788 78,800 0.00000132 ETH ($0.0043)

A few observations:

  • High success rate: Both addresses are running reliable infrastructure (788/795 and 1378/1378 success rates)
  • Competitive pricing: The implied price per AZTEC ranges from $0.0031 to $0.0043, reflecting different gas optimization strategies
  • Limited by rate: With only 1 flush possible per epoch currently, a max of 3800 AZTEC tokens were released per day. The impending governance proposal if passed will increase this to 15,000 AZTEC tokens a day.

Get Involved

The Flush Rewarder is live and funded with ~855,300 AZTEC available as of the time of writing. If you’re comfortable running a bot that monitors the entry queue and submits flush transactions, you can help maintain the Aztec validator set operations.

Contract Addresses:

  • Flush Rewarder: 0x7C9a7130379F1B5dd6e7A53AF84fC0fE32267B65
  • Rollup: 0x603bb2c05D474794ea97805e8De69bCcFb3bCA12

Questions? Drop them below.

2 Likes

Why not require flushEntryQueue() for block submission?

Why not require flushEntryQueue() for block submission?

  • It makes every block / epoch more expensive even when there’s no one in the queue to flush.
  • Sequencers / provers shouldn’t bear the cost of getting other sequencers into the set.
  • Since FlushRewarder is a non-protocol contract (it is not needed as you can call the rollup contract directly), we removed complexity from core contracts.

If token holders are going to pay for validator-set updates, then those payments should be efficiently priced. Instead of a fixed 100 AZTEC, target an inclusion rate with dynamic pricing (or some other auction mechanism). e.g. Target wait time = 1 epoch, with payments adjusting if early/late.

1 Like

I agree that this would be a nice addition to the Flush Rewarder contract in a future upgrade. Since this contract is out-of-protocol, Aztec Governance would just have to deploy a new Flush Rewarder and fund it to be able to use it. So it’s a rather low-stakes upgrade.

It’s seem there is one wallet can do this is : 0x088138d4c86fd93b7ef1d50918dcd02aedf82d18
When proposal increase queue throughput apply?