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..
