AZIP-5 Optimize Prover Rewards for Consistency

[EmrePiconbello]

I would like to open this to discussion. Because of many other commitments, I could not release it first and then could not convert to the new AZIP format, but since the Alpha upgrade is here, it is time. The consistency of the provers is much more important. We just had an epoch that got pruned, while our prover saved 2 to 3 epochs in the last 2 to 3 days. While we are creating a platform here and we want the ecosystem to grow and applications to be built, etc., if we have these prunes often enough that they disrupt the user experience or the developer experience, it is because they cannot predict them, and thus they cannot build products around them. In the long run, all these aspects just hurt the ecosystem further. While I cannot know all the participants' current intent, there are significant multiple accounts extracting 70 to 80 percent of the pool. If they are going to invest back into the ecosystem and become consistent provers, that is good; but in general, from my experience, the likelihood of this happening is less than 1 percent, and it just makes the whole economic structure and the rollup health fragile, so there should not be a reason for this to be this easy. There will always be value extraction, and blocking it is hard. Since there will not be consistent transactions on L1, that is also a bit of a concern, and if it becomes much worse, we might need to create a much more complicated contract, perhaps holding proof rewards for a certain amount of epochs and slashing for misbehavior. As long as the ecosystem grows, people utilize Aztec, and some random gas spikes happen, these numbers should keep multiplying by 10, resulting in a waste of money, as they will only get 1 percent of the pool versus 10 percent from before per prover. Considering ether gas, that amount of share should not cover the gas cost, and unless they commit, they should not be able to grow their share.

[pittpv]

Undoubtedly, this topic is important for the network, and there is a large share of truth and correct solutions in it. However, economic benefit is one of the strongest factors — you can't rely on enthusiasm alone for long.

It's clear that the proposed solutions will drive out small providers (provers), but this will not guarantee the elimination of multi-accounts — because both now and if the proposed changes are implemented, they have and will continue to have sufficient funds to maintain their infrastructure. Right now, I already know what resources are being used — and these are very serious and expensive machines.

How this will affect decentralization — I think it's obvious. Certainly, the topic of prover rewards is an important topic.

[EmrePiconbello]

As long as we have some transactions or gas spikes in a week, it does. Multiple accounts are doing this because they can do it without the cost; also, they profit so much from that because their cost is near zero while they collect the majority of the pool. There is no multi account doing expensive epochs because it is just burning money. Currently, the whole pool is about 5000 AZTEC. For a simple calculation, with a 2 prover and 10 multi account example, in a gas spike, a multi account needs to pay 100 USD in gas. If 10 multi accounts do this, they spend 1000 USD, and as a result, the multi account gets 4166 AZTEC, which is 90 USD in rewards. If it skips 2 epochs, then for a 10 prover, it only gets 230 AZTEC, which, even at the lowest gas prices, hardly covers the gas cost. There is also a hardware cost, so without investment and commitment, it cannot extract anymore, and since the amount of investment requirement is high, multi account means it eats into its own margins because rewards are fixed. In the current system, without any activity, in the same example, only 2 provers are sharing the pool, and someone just joins with 10 multi accounts with zero activity points. The issue is that without any investment, they always get 10 percent of the pool, so with 10 accounts, it starts to share the pool 3 ways, with the other 2 collecting 1666 AZTEC, while the 10 prover multi account also collects the same amount. With only acquiring a cheap epoch, keep collecting points and reach max activity, then start collecting 4166 out of the 5000 total pool. It can keep doing that because a prover can miss 1 out of 5 epochs and retain the share. A multi account works because the cost is near zero, and since the cost is close to zero, currently running a multi account gets rewarded with more rewards, even though the reward pool is fixed as they collect more share for free.

[htimsk]

Overall position: supportive. AZIP-5's direction, rewarding consistent, committed proving and ending the cherry-pick economics, is the right one for the long-term health of the prover set and the protocol. The parameter-only approach is also exactly right: it's deployable now, fully reversible, and avoids contract-deployment risk. The comments below are intended to tighten the proposal within that scope, not to oppose it or to push for changes to smart contract code.

1. Please specify the score-migration mechanism explicitly. With the new maxScore of 367,500, what happens at the moment the parameters are updated on-chain?

   • Are existing scores clipped at the new maxScore (everyone above 367,500 starts at the new cap)?
   • Are they proportionally rescaled (15M → 367,500, 12M → 294,000, etc.)?
   • Are they left untouched (stored as-is, but the share formula now uses the new maxScore constant, meaning everyone above 367,500 is effectively at-or-above-max)?
   • Or do scores reset to zero, forcing the full 7-day ramp for every existing operator?
     Each option has very different implications for fairness and continuity, and operators need to plan for them. Adding an explicit one-line statement to the Specification would resolve this.

2. Please specify activation timing and any pre-activation notice window. Operators with infrastructure decisions to make (consolidation, hardware sizing, redundancy investment) need a minimum lead time between governance approval and parameter switchover. A stated notice window (e.g., "≥ N epochs after vote passes") in the Specification would help.

3. Confirm k (the share-formula maximum) stays at 1,000,000. The proposal lists four parameters but the share formula share = max(k - a*(maxScore-score)²/1e10, minimum) also depends on k. The proposal implicitly assumes k is unchanged. A line in the Specification confirming this would close the spec.

4. Alternative softer parameter set within the same four-lever scope. The proposed values are aggressive in two specific places — the 75%→1% cliff at the 2-miss threshold and the 71-epoch single-miss recovery window. Both can be smoothed without changing the proposal's intent (consistency wins, cherry-pickers lose) and without going outside the four parameters in the proposal. Here are some alternative settings I would suggest for consideration:

   Param	Current	AZIP-5 proposed	Softer alternative	What it changes
   increment	125,000	101,400	110,000	Single-miss recovery 71 → 10 epochs (~1.9 days → ~6.4 hr)
   maxScore	15,000,000	367,500	367,500 (keep)	Same compression
   a	1,000	250,000	100,000	1/2/3-miss share goes 90/60/10% instead of 75/1/1%
   minimum	100,000	10,000	10,000 (keep)	Same floor

   Effect: break-even still moves to ~96% (well above today's ~78%), and intermediate provers still lose meaningfully. This may also reduce the centralization pressure noted in point 4.

[EmrePiconbello]

1. Please specify the score-migration mechanism explicitly. With the new maxScore of 367,500, what happens at the moment the parameters are updated on-chain?
   It got reset to 0. We are deploying a new contract, and unless the alpha where the score is stored changed, it will reset to 0. Resetting to 0 means everyone is equal, so when everyone reaches max points, they share equally. When they get reset to 0, they still share equally, so there is no disruption from that perspective.

2. Please specify activation timing and any pre-activation notice window. Operators with infrastructure decisions to make (consolidation, hardware sizing, redundancy investment) need a minimum lead time between governance approval and parameter switchover. A stated notice window (e.g., "≥ N epochs after vote passes") in the Specification would help.

Activation is going to be much faster, but with voting and many other aspects, it takes a while, and it might wait to be bundled with other AZIPs as well. It is impossible to know right now when it gets on chain voting, but you will know all the timeframes.

3. Confirm k (the share-formula maximum) stays at 1,000,000. The proposal lists four parameters but the share formula share = max(k - a*(maxScore-score)²/1e10, minimum) also depends on k. The proposal implicitly assumes k is unchanged. A line in the Specification confirming this would close the spec.

Yes I confirm it doesn't change.

4. Alternative softer parameter set within the same four-lever scope. The proposed values are aggressive in two specific places — the 75%→1% cliff at the 2-miss threshold and the 71-epoch single-miss recovery window. Both can be smoothed without changing the proposal's intent (consistency wins, cherry-pickers lose) and without going outside the four parameters in the proposal. Here are some alternative settings I would suggest for consideration:

The issue is that while softer parameters would be nice, they will not be enough to filter. A 6.4 recovery rate means one miss is recovered in 10 epochs, which is not that different from missing 1 out of 5 epochs. Epochs are 38 minutes apart, which provides a large window. From an uptime perspective, it is also a very low number. I am just coming up with a random number, but currently 95 percent of the epochs are free. The issue is that anyone who invests in actually covering the expensive ones that a rollup needs to rely on in the long run, with the chain continuing to expand and needing so much more compute, will require much more investment. The problem is that there will never be a constant load of expensive epochs. To cover 1 tps, let us say the monthly cost is 5000 USD. They spend that money to cover those spikes so that the rollup does not get pruned, because every single prune is very damaging for the rollup and every single participant in the ecosystem. App developers, users, and everyone else. If we do not fix this and leave it loose, then we will have a bunch of extractors that extract when there is no activity. They might put resources into proving 0.1 tps transactions because it would still be cheap to do, as the majority of transactions could be in that range and it rarely spikes. If we move the goalposts, they will just adapt. This will not even work if we do not have enough on chain activity. In the long run, if we do not have provers that invest in it and become sustainable, they will disappear. While I say this is bad, we need 3 or 4 reliable provers. Depending on how many of them could be sustainable, we need that number. Currently, they cannot do it because they will just lose money, as all the cheap epochs that should recover their losses are split among 20 or 30 participants that do not do any expensive epochs.