[ACP-255] New Curve Model for L1 Validator PAYG Fee

[iJaack]

This PR proposes a new Gaussian bell curve fee model for L1 validators, replacing ACP-77's flat-fee structure. Combined with L1-size-dependent multipliers, it dramatically increases AVAX burn while incentivizing validator decentralization.

Problem

Current ACP-77 model:

• Insufficient burn: Only 1,064 AVAX/month at 800 validators
• No decentralization incentive: Flat fees favor single-validator L1s
• Misaligned growth: Network expansion provides no economic benefit

Solution

L1-Size Multiplier: Cost plateau at 10-15 validators makes validator set growth economically irresistible (15-validator L1 costs same as 1-validator, but 15x more secure).

Gaussian Network Factor: Bell curve centered at 10,000 validators creates time-dependent incentives—high burn during bootstrap, peak at critical scale, graceful decay as network matures.

Expected AVAX Burn Rates

Network	Validators	Current	Proposed	Increase
Current	800	1,064	9,040	8.5x
Growth	5,000	6,650	97,800	14.7x
PEAK	10,000	13,300	266,200	20.8x
Sustainable	50,000	66,500	347,000	5.2x

(AVAX/month burned)

Benefits

• Deflation: 8.5-20.8x higher AVAX burn strengthens long-term value
• Decentralization: Cost plateau eliminates incentive for single-validator L1s
• Growth Alignment: Network expansion reduces per-validator costs, creating adoption spiral
• Elegance: Continuous smooth curve, no discontinuities

Implementation

• Base rate doubled (512 → 1,024 nAVAX/sec)
• L1 multiplier: 1.0x to 18.84x based on validator count
• Network factor peaks at 3.84x at 10,000 validators

(Sorry for the commit mix-up, I created the ACP-247 PR in my main branch, I now have separate branches for each ACP)

[ericlu-avax]

Here are my questions/comments:

1. Could you add the exact formula for the bell curve? I understand the location parameter is 10,000. What is the scale parameter? Could you also provide the exact fee rate formula?
2. Could you explain the assumptions you made on the life-cycle validator count for an L1?
3. Could you add the comparison on the marginal cost in terms of registration fees of each additional validator under the current and the proposed fee mechanisms? Relatedly, how would you expect the proposed change affect the equilibrium/optimal validator count for an L1?
   Thank you.

[iJaack]

Hi @ericlu-avax ,

Could you add the exact formula for the bell curve? I understand the location parameter is 10,000. What is the scale parameter? Could you also provide the exact fee rate formula?

the exact formulas are in the file, rewriting here for convenience:

Formulas:

for the fee multiplier:

$$ \text{multiplier}(n) = 1.0 + 17.84 \times e^{-0.3 \times (n-1)} $$

for the bell curve:

$$ \text{networkFactor}(V) = 1.0 + 2.84 \times e^{-\left(\frac{V - 10,000}{7,500}\right)^2} $$

for the fee curve:

$$ \text{feeRate}(V) = 2.65 \times \text{multiplier}(n) \times \text{networkFactor}(V) $$

Could you explain the assumptions you made on the life-cycle validator count for an L1?

Can you rephrase? The only assumptions I made are based on the average number of validators per L1, and that is under <10 and more around 5, and that there are two macro types of L1s that can exist: enterprise or community ones, with the formers likely wanting to have greater control over their validator set (so keeping it under 10) but at the same time having the budget to maintain at slightly higher costs, and the latter being generally L1s that want to thrive by having a large validator set / community.

Could you add the comparison on the marginal cost in terms of registration fees of each additional validator under the current and the proposed fee mechanisms? Relatedly, how would you expect the proposed change affect the equilibrium/optimal validator count for an L1?

What do you mean by 'registration fees'? If you are talking about actual 'addition' txs on the P-Chain, those are negligible in my calculation, being a fraction of a single AVAX (a few dollars at most at current prices). If you're talking about server costs and related, I have not taken those into account, and I don't think they should be taken into account because, again, the only big difference in costs would be for enterprise, smaller-than-10 validator sets that can surely absorb the costs just like they incur in server costs for other backends they use.

It may be a simplistic assumption, but my vision is that ACP-255 would be tightly coupled with #247 to ensure L1 validators are also rewarded from Primary Network validators and can offset potentially any extra cost generated by ACP-255.

Eager to read your response!

[michaelkaplan13]

This doesn't formula is not displayed correctly: https://github.com/iJaack/ACPs/tree/acp-255/ACPs/255-new-curve-model-for-l1-validator-payg-fee#2-l1-size-dependent-fee-multiplier

[michaelkaplan13]

The current PAYG fee mechanism is actually not a flat-fee model. It is a dynamic fee model with a minimum fee of 512 nAVAX/sec, and a target of 10,000 L1 validators. When the target is exceeded, the fee rate begins to rise exponentially until the total number of validators returns to the target. When the total number of validators is beneath the target, the fee rate decreases down to the minimum.

(specified by ACP-77 here)

[iJaack]

Yes, you're right, it's mainly flat, going to edit this to reflect it.

But I wanted to clarify first: what's the reason behind the exponential increase after that threshold @michaelkaplan13 ?

[ericlu-avax]

Yes, you're right, it's mainly flat, going to edit this to reflect it.

But I wanted to clarify first: what's the reason behind the exponential increase after that threshold @michaelkaplan13 ?

This is related to my earlier question about life-cycle validator count for an L1. Under the current mechanism, the fee rate at second depends on the validator count. So the total fee generated by a chain is the sum of fee paid at each second, which is determined by the process of validator count from the birth of the chain to the end of the chain, or to perpetuity if the chain lives forever.

[michaelkaplan13]

The maximum number of L1 validators is 2x the target of 10,000, so there can not be anymore than 20,000 in total currently.

[iJaack]

Oh OK, is there a documentation link to support that? Would love to dive into it.

[ericlu-avax]

Oh OK, is there a documentation link to support that? Would love to dive into it.

Here you can see 20,000 is the validator capacity: https://build.avax.network/blog/l1-validator-fee

[michaelkaplan13]

Unfortunately, this also present a DOS vulnerability for the P-Chain and primary network as a whole.

Each additional L1 validator uses up more resources for primary network validators to track, and thus must result in additional fees being paid.

I like the idea of each validator paying less the more validators there are, but it must be the case that in aggregate, more fees are paid for each additional validator.

[michaelkaplan13]

This also doesn't display correctly: https://github.com/iJaack/ACPs/tree/acp-255/ACPs/255-new-curve-model-for-l1-validator-payg-fee#3-gaussian-network-factor