Proposal: Optimizing prover rewards for more consistency

[emrepiconbello]

Summary

This proposal updates parameters in the RewardBooster contract to more aggressively penalize low-coverage provers while preserving recovery time and break-even thresholds for reliable provers.

Parameter	Current (on-chain)	Proposed
increment	125,000	101,400
maxScore	15,000,000	367,500
a	1,000	250,000
minimum	100,000	10,000
k	1,000,000	1,000,000

decay_rate remains at 100,000 per epoch as it’s not in config variables. I didn’t want to complicate the proposal.

Motivation

Under the current parameters, the reward boost curve is extremely flat; a prover with only 78% coverage still earns roughly 44% of the maximum reward share. This means provers who cherry-pick cheap epochs face almost no economic consequence, undermining the incentive to prove consistently. While margins are currently high for protocols because blocks are empty and can be proven, the protocol is only able to cover a few provers. While that is not optimal, for protocol health, we need provers to be sustainable. As load and application transactions increase, a 1 TPS requirement will necessitate 200 agents with 32C/64T CPUs and 128GB RAM per agent. This kind of hardware costs a lot of money, and the main proving cost becomes hardware, whereas right now it is near zero. Since the chain will never be under a constant steady load, there will be times with many transactions and times with fewer, but a prover needs to cover the highest limit. Otherwise, all sequencers in that committee get slashed and the blocks are pruned, which is not good for the chain or anyone from users to developers in the ecosystem. Covering the network costs a lot for the prover, and because network load will not always be consistent and there will be empty blocks, it is currently very prone to value extraction. While we cannot ever block it fully, with this proposal, we make it much harder for short-term and inconsistent provers to achieve a share in the pool so that actual provers can be more consistent and sustainable.

How It Works

The share formula in RewardBooster._toShares() is:

share = max(k - a * (maxScore - score)² / 1e10, minimum)

Each epoch, a prover’s score decays by 100,000. If they submit a proof, it increases by the increment. The net gain per proof is +1,400, meaning a prover must prove ~98.6% of epochs just to maintain their score; this is the break-even threshold.

Miss cascade from max score

Consecutive misses	Share (% of max)	Effect
0	100%	Full reward
1	75%	Severe hit
2	1%	Minimum floor
3	1%	Minimum floor

Recovery from zero back to the max score takes 262 epochs (~7 days). Recovering from a single miss takes ~71 epochs (~1.9 days). In the current system, reaching the max score takes 16 days, and getting to the minimum score takes 4 days of no proposals, while the minimum reward share is always at 10%. After 10 consecutive misses, a prover is still rewarded at 90%, while at the max score, if they miss one out of every 5 epochs, they can retain the near-perfect max reward rate. The changes I propose make it harder to retain high rewards; however, because punishment and reward reductions are significant, it also takes less time to reach the max score. The proposed system allows 1 epoch miss every 2 days with very moderate reward loss.

**Risk Assessment
**
1)We are just changing the config variables in the defined method. There is no smart contract risk.
2)In case of bugs or issues with the protocol where every prover is affected and unable to send proofs, resulting in deducted reward shares, everyone is deducted equally. This means their share percentage stays the same, so there is no risk of making things unstable or breaking the economic structure completely.
3)If the parameters prove too aggressive, a new governance proposal can adjust them.

I am adding the payload and the some comparison chart from the epoch range in this repo

Since the alpha upgrade is coming and will change the rollup address, I am not sure how this should be proposed. Should it target the new or the old rollup address? There is also the AZIP process, which was announced recently. I am not sure how to follow up with those as I have not had time, but I did not want to delay this further, so I am sharing it here for discussion. Since this is just a configuration change, I am in favor of deploying it on the rollup as soon as possible. Hopefully, I can get support for it.

There are a few things I want to point out. The total pool of rewards for provers is 15,133,800 AZTEC between epochs 236 to 4,682, totaling 4,443 epochs. 44.1% of it (6,677,983 AZTEC) was earned by a single operator, 0x6bf706f287b4e86d27dabb10305bae59720720a4. With these changes, this operator’s rate across the board goes down to 37% because, while many of its provers have low coverage and lose to changes, some have high coverage and those benefit from higher rewards. Currently, maintaining consistency is not that hard because computing the proof is near zero, but after the update, that will not be the case, so they will be reduced significantly more. If we do not solve this, actual provers that prove all epochs and invest in hardware might not achieve sustainability, and we might not have provers to cover the chain anymore. The biggest gainer of this change is 0xA5c7857Bf8C8220403CAf189066CE5bac4462705, which consistently proved nearly all epochs without a miss since they started. Two days ago, it looks like they hit a bug and are currently not proving. For situations like this, while decay is faster, claiming the max reward rate is also significantly faster. As long as a prover proves the compute-heavy, expensive epochs along with all the cheap epochs, my aim here is to minimize economic value extraction with the upcoming alpha upgrade. With current variables, anyone that proves 4 out of 5 epochs can retain the max reward, and since on-chain activity is not constant, there will be many moments where proofs can be generated cheaply, which can lead to 10 to 20 duplicates by a single operator. As the chain has more activity and transactions, these kinds of extractions should be at a low level, as 2 heavy epochs that they do not compute in a week would put them back to the minimum reward level..

[ThreeMuskets]

I think this proposal makes a lot of sense. This allows us to give substantially better economic stability to “real” provers by reducing the amount of rewards taken from “prove sniping” cheap blocks all without changing the economics of the % of AZTEC issuance dedicated for paying for proving.

Great proposal, I’m in favor.

[koenmtb1]

Love to see these suggestions @emrepiconbello
We recently introduced the governance framework, see Introducing the Aztec Governance Process

To get started, I suggest posting this to the Github Discussions on the Governance repo. We have ongoing weekly calls discussing governance, would be great to see you there to discuss this!

[CitizenWeb3]

Support this direction. Reward structures should favor operators who invest in consistent, reliable infrastructure over those sniping proofs opportunistically.

The 98.6% coverage threshold is demanding but fair imo. Operators running on bare metal with proper redundancy - UPS, failover connections, monitoring, should clear that bar consistently. Those who can’t maintain it probably aren’t running the kind of infrastructure the network needs long-term.

I would have questions about MPC but i dont have numbers. Bare in mind that on other chains, where various sorts of MPC are live and used. Nodes that run baremetal and MPC do have some drops in numbers, but usually its not that much.

Two observations:

1. The config-only approach is smart. It lets the network iterate on parameters without smart contract risk. If 98.6% turns out too aggressive post-upgrade (given the v4 changes landing around March 30), the community can adjust.

2. Protocol-wide outage handling is probably a good call, considering the architecture of the network

We operate Aztec sequencer nodes on self-hosted baremetal with multiple failover layers (broadband + Starlink), UPS, 24/7 monitoring. Consistency-rewarding economics aligns with how we build infrastructure.

[The-CTra1n]

Nice proposal. I like the way 2+ slot misses basically reset rewards to 0 for a prover.

I don’t have any major concerns about the parameter changes you propose, they seem quite reasonable.

One thing I might be interested in testing would be decay rate =180k, and increment =101,800 / 102,500/103,600?

All else being equal, this would effectively reset a prover’s share to minimum after a missed epoch, but this can immediately start increasing above minimum if it is just a single miss. It’s a little more extreme than your suggestion, but would better target the 99% uptime goal of the network – if a prover’s breakeven point is ~50%. I’m a bit concerned that cutting to 75% after a miss isn’t harsh enough. For example, if 75% is above the breakeven point for provers, provers are happier to target something like 98% uptime, or less.

Basically, it all depends on how many provers we want to sustain, and where we expect the weakest prover’s breakeven point to be. Starting with your parameters sounds like a good place to start though

[emrepiconbello]

@The-CTra1n

One thing I might be interested in testing would be decay rate =180k, and increment =101,800 / 102,500/103,600?

I did not touch the decay rate because it requires a new contract deployment and I want this to be activated as soon as possible. The decay rate is constant on the contract. I am not sure about the update process exactly, but from my understanding, all others are variables that can be changed, so the upgrade process for it is much simpler and faster. Otherwise, I would like to adjust it as well, but I came up with all the numbers under the limitation of the decay rate being 100k constant.

@The-CTra1n

For example, if 75% is above the breakeven point for provers, provers are happier to target something like 98% uptime, or less.

I agree, and those numbers look scary, and they are the only way I found under the current economic parameters of Aztec. The uptime part is not a constant uptime. You can have downtime of 20 minutes and still have 100% uptime in the system. Uptime is calculated per epoch proof, and since the window is so wide, we target a bit less than that, which allows missing 2 to 3 epochs in the 48 hour window. In the 48 hour window, if there is not a big spike of multiple transactions or a gas spike, then we cannot be efficient at punishing extractors. If we want to keep the uptime but make the breakeven point lower, that requires a block reward and prover share percentage adjustment or completely designing a new reward boost contract, which is more sophisticated. All of these require much more discussion and time to develop. While this proposal is the fastest solution because it just changes the variables on the reward booster contract, it does not affect anything other than how the prover shares split.

[The-CTra1n]

@emrepiconbello

. If we want to keep the uptime but make the breakeven point lower, that requires a block reward and prover share percentage adjustment or completely designing a new reward boost contract, which is more sophisticated. All of these require much more discussion and time to develop.

Completely agree. I did a very quick simulation on a block reward adjustment to target a specific number of provers – like EIP1559, increasing reward when below the proof submission target per epoch, decreasing reward when above the target.

TLDR: We considered a reward change for provers, using a mechanism based on a target number of provers. Although in the short- to medium-term it could reduce direct protocol issuance on provers and improve the number of provers and the resilience of the proving network during high usage periods, it comes with complexities, costs, tech debt, and unknowns around whether issuance would actually reduce (cartel risk) which make it hard to justify without exploring @emrepiconbello’s simpler proposed alternative first, and focusing R&D efforts on increasing L2 usage in the meantime.

This analysis is based on some Claude-assisted and brief fiddling around with the Aztec prover reward parameters (<1 day spent on this). The code to re-run the simulation is available here.

---

The consequence of many provers being active when costs are low means even the committed provers can’t justify the L1 costs / hardware investment needed to perform proving during peak L1 / L2 usage, which means provers won’t have enough resources to prove and submit during peak usage times.

As such, I tried to understand address the implicit goal of “targetting a specific number of provers in the system at any given time”.

The protocol is simple, set a target number of provers, and adjust prover rewards depending on how many provers submit a proofs, namely:

• reduce prover rewards when more than the target number submit

• increase prover rewards when less than the target number submit.

Continuing the Analysis vs Stopping

The initial results indicate savings are possible, but the unknowns are significant and together, these unknowns likely warrant the stopping of further research into the change, for now at least. Such a change can be revisited later, especially if the suggested param changes in the original post are unsuccessful.

Possible Savings (ignoring implementation costs & tech debt) — the motivation for continuing

This model’s lowerbound expected savings at a 2 prover target are $42 per epoch, or $550,000 per year (plus reduced sell pressure on Aztec token), assuming no prover fees being received from user txs —tx fees would further reduce the equilbrium block rewards being paid == more savings.

• With a target of 2 provers always on, 0.02$ per Aztec,

  • at $10 per proof submission (equivalent to 1.1 Gwei, average of gas costs in the last 2 weeks) and:

    • $1 per epoch proof (current Claude estimates for the minimum harder requirement for proving), the protocol would save ~3000 Aztec, or $60 per epoch.

    • $10 per epoch proof (10x the no usage number), the protocol would save ~2100 Aztec, or $42 per epoch.

  • at $1 per proof submission (equivalent to 0.1 Gwei, close to the costs around alpha launch, indications we are returning to this price regime), and:

    • $1 per epoch proof, the protocol would save ~4300 Aztec, or $86 per epoch.

    • $10 per epoch proof, the protocol would save ~3600 Aztec, or $72 per epoch. (This number could be closer to the $10 proof submission, $1 proving cost number, a consequence of quick simulation and choice of distributions).

Aside from these savings, it is good practice to have a reward which purposefully targets its goal. In this case, funding provers to maintain liveness while the network usage increases. To this end, we want to subsidize a small number of reliable provers, rather than many provers when L1 costs are low and potentially none when costs go high.

Reasons for not pursuing the idea further:

• If we set the target to 3 or more provers, the savings reduce — and there is a decent argument for a target of 3 or more. Ideally, we can allow the target adjustment to take affect when there are still 2 provers active, for redundancy. With a target of 2, we can only increase rewards if we are at 0 or 1 provers active, a fragile state for the system to be in.

• Target provers may lead to prover cartels, incentivized to tune the reward higher than needed to extract profit from proving. Right now, this isn’t a concern as the barrier to entry is low, but if the barrier to entry gets high, the active provers can agree to share rewards and drive up the equilbrium prover reward far beyond the 4800 per epoch currently being paid.

• This reward change could be seen as tech debt if long term plans are to remove issuance.

• The target prover change can be applied with or without the simpler param change of the current forum suggestion. The easier path is apply the forum changes first, focus efforts on other endeavours and revisit target provers if prover number issues persist.

• Aztec has done prover reward analysis internally, 4,800 is likely tuned for the correct number of provers GIVEN a minimum certain usage and user fees. Changing this number/mechanism now while we are still in low usage might be premature.

---

Aside: Currently, Aztec allocates 500 Aztec in issuance per checkpoint (16,000 for a 32 checkpoint epoch) for sequencing and proving, split 70:30, meaning 4,800 Aztec per checkpoint for prover rewards. This is split evenly among all provers who submit a valid epoch proof.