[ACP-255] New Curve Model for L1 Validator PAYG Fee by iJaack · Pull Request #255 · avalanche-foundation/ACPs

iJaack · 2025-12-11T17:18:09Z

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 · 2025-12-29T13:41:52Z

Here are my questions/comments:

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?
Could you explain the assumptions you made on the life-cycle validator count for an L1?
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 · 2026-01-08T11:45:54Z

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 · 2026-01-14T21:47:00Z

ACPs/255-new-curve-model-for-l1-validator-payg-fee/README.md

+This ACP proposes to introduce a new formula to account tied to the number of validators of a given L1.
+
+**Formula:**
+$$ \text{multiplier}(n) = 1.0 + 17.84 \times e^{-0.3 \times (n-1)} $$


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 · 2026-01-14T21:49:31Z

ACPs/255-new-curve-model-for-l1-validator-payg-fee/README.md

+
+## Motivation
+
+The current ACP-77 flat-fee model provides insufficient burn (~1,064 AVAX/month) and creates no economic incentive for validator decentralization. ACP-255 implements a smooth Gaussian fee curve that:


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)

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 ?

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.

@ericlu-avax in this new model, the total fees paid by a chain would be the same, but instead of just being dependent on global validator count, it would also be dependent on the single validator set.

Does that make sense? Does this answer the question?

michaelkaplan13 · 2026-01-14T21:50:58Z

ACPs/255-new-curve-model-for-l1-validator-payg-fee/README.md

+- At 5,000 validators: **14.7x higher burn** (6,650 → 97,800 AVAX/month)
+- **At 10,000 validators: 20.8x higher burn (PEAK)** (13,300 → 266,200 AVAX/month)
+- At 20,000 validators: **8.2x higher burn** (26,600 → 218,000 AVAX/month)
+- At 50,000 validators: **5.2x higher burn** (66,500 → 347,000 AVAX/month)


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.

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

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

Thank you @ericlu-avax , edited the text to account for the 20,000 validator limit.

michaelkaplan13 · 2026-01-14T21:53:47Z

ACPs/255-new-curve-model-for-l1-validator-payg-fee/README.md

+| L1 Validators | Multiplier | Fee/Validator | L1 Total |
+|---|---|---|---|
+| 50+ | 1.00x | 2.65 AVAX | Variable |
+| 15 | 1.27x | 3.36 AVAX | 50.46 AVAX |
+| **10** | **2.20x** | **5.84 AVAX** | **58.36 AVAX** |
+| 5 | 6.37x | 16.91 AVAX | 84.57 AVAX |
+| 1 | 18.84x | 50.00 AVAX | 50.00 AVAX |


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.

You're right, and in the meantime I edited the ACP so that it better reflects the 20,000 validator limit.

If still brainstorming how to make it so that after 10,000 validators there's a clear change

michaelkaplan13 · 2026-01-14T21:54:16Z

ACPs/255-new-curve-model-for-l1-validator-payg-fee/README.md

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


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

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

iJaack · 2026-02-19T13:51:48Z

Just cleaned the commit list for this PR to ensure it's not mixed with other ACPs.

Would love to get more feedback as to if this proposal is doable, maybe in multiple steps.

cc @michaelkaplan13 @ericlu-avax

michaelkaplan13 reviewed Jan 14, 2026

View reviewed changes

iJaack added 7 commits February 19, 2026 14:50

Add core formulas section

296e731

Add L1 validator growth assumptions

e2c0749

Add marginal cost comparison

674e528

Add game-theoretic equilibrium section

94fc5e2

Add ACP-247 interaction section

b31c913

Misc fixes and 20k validator cap

7b2ec86

iJaack force-pushed the acp-255 branch from ad11a12 to 7b2ec86 Compare February 19, 2026 13:50


		## Motivation

		The current ACP-77 flat-fee model provides insufficient burn (~1,064 AVAX/month) and creates no economic incentive for validator decentralization. ACP-255 implements a smooth Gaussian fee curve that:


		Formula:

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

Conversation

iJaack commented Dec 11, 2025

Problem

Solution

Expected AVAX Burn Rates

Benefits

Implementation

Uh oh!

ericlu-avax commented Dec 29, 2025

Uh oh!

iJaack commented Jan 8, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ericlu-avax Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iJaack commented Feb 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ericlu-avax Jan 15, 2026 •

edited

Loading