Periodic manual configuration of minimal base fee

📜 Development Proposals Starknet Technical Development
1

Motivation

At the moment, fees paid by Apps to Starknet move sharply as a function of the STRK price. This is suboptimal for both dApps and the Starknet sequencers - as the majority of income (for dApps) and expenses (for sequencer) are denominated in $$. This creates unpredictability for all sides as STRK price shifts.

While an automatic solution for this problem is currently in the design phase and a SNIP around it will be released soon, the current suggestion is to perform this alignment manually in the very near future before the automatic feature receives feedback, matures, and gets into production.

Concrete Suggestion

  1. A concrete $$ cost will be aligned to L2gas. Concrete initial value: $10^-9 fee per L2gas. This is in line with the fee that was on the network immediately after the 0.14.1 launch.

  2. This baseline needs to be re-evaluated periodically as the protocol undergoes changes that improve its efficiency, change the L2gas weights, etc.

  3. Every Thursday, the average STRK price within the last week will be used as a baseline and a new hypothetical base fee will be calculated.

  4. If the hypothetical base fee significantly deviates from the current base fee, it will be posted in this thread at the community forum, to take effect starting the following Monday (starting early morning hours UTC)

  5. On the Monday after this, assuming price change is needed, the minimal base fee will be set accordingly. The team will apply an “incremental” logic where base fee will slowly shift towards the new price (if higher) or drop in one go (if lower). The shift will be identical to 1559-native climbing/dropping rate. In more details:
    a. If the current base fee is lower than the newly-configured minimum base fee, all the blocks will be treated as 100% congested and the fee will gradually increase accordingly until it arrives at the new set minimum.
    b. If the current base fee is higher than the newly-configured minimum base fee, and there is no congestion, base fee will slowly get back to the newly configured minimum.

2

Update: 7-days average STRK price is $0.048, bringing to 20.8gFri/L2gas to get to the target of $10^-9 per L2gas. (compared to current price: 8gFri/L2gas)

Change will take place on Mon 16.02, around 8:30am UTC. A concrete block height from which the change will start to take effect will be published by 7:30am UTC within the same day

3

Noted. Sharing this in Discord + Twitter so builders don’t miss the Monday change :loudspeaker:
For anyone tracking:
• New base: 20.8 gFri/L2gas
• Takes effect: Mon Feb 16, ~8:30am UTC
• Block height: Published Mon at 7:30am UTC

This is exactly the kind of proactive communication that makes Starknet governance work. Clear timeline, concrete numbers, advance notice.

Thanks for keeping the community in the loop, Ohad :folded_hands:

4

On top of posting it to this thread, I’d also notify, if possible, node operators.
Imho, every change, unless minimal, should be forwarded on all channel available.

5

Could you also add the previous cost, to be able to compare easily before/after

6

done (and will do), thanks for the suggestions

7

This is a great example of pragmatic governance shipping a manual solution while the ideal automatic system is being designed. A few community-oriented thoughts:
On Communication Cadence:
You mention posting updates “in this thread at the community forum” every Thursday. Suggestion: also cross-post to Discord (#announcements) and Twitter for visibility. Not all builders actively monitor forums, but fee changes directly impact their bottom line.
Could we create a dedicated “Fee Alignment Updates” category in the forum so these threads are easy to find historically? Would help new developers understand the evolution.
On Predictability for Builders:
The Thursday calculation → Monday implementation timeline is excellent. Builders get a 4-day heads-up before any change takes effect.
Request: Could we get a simple dashboard (even a Dune Analytics query) showing:
∙ Current base fee (in STRK and $$ equivalent)
∙ Next scheduled adjustment date
∙ Historical base fee changes
This would help dApps budget accurately and reduce surprise factor.
On the “Incremental” Upward Logic:
I understand the rationale (avoid shocking users with sudden fee spikes), but I want to make sure this is communicated clearly to app developers.
If STRK price doubles overnight but fees take a week to gradually adjust upward, dApps get a temporary subsidy (paying less in real $$ terms). That’s great for them, but sequencers bear the cost.
As we move toward decentralized sequencing, we need community consensus on: who should absorb short-term volatility risk users/dApps or sequencers?
This manual phase is the perfect time to gather data and have that conversation before locking in the automatic mechanism.
On Periodic Re-evaluation:
You mention re-evaluating the $10^-9 baseline as protocol efficiency improves. Who decides when efficiency has changed enough to warrant adjustment?
Suggestion: Tie reevaluation to major protocol upgrades (e.g., post-hardfork, after prover improvements ship). This makes it predictable rather than subjective.
Bonus: Publish a “fee efficiency changelog” after each upgrade showing how L2gas costs have improved. This transparency builds trust and attracts cost-sensitive builders.
On the Broader Vision:
This manual alignment is a stopgap, but it’s also a live experiment. The data collected here (STRK volatility vs fee stability, dApp cost predictability, sequencer margins) will directly inform the automatic SNIP.
I’d love to see a retrospective after 3-6 months: What worked? What didn’t? What edge cases did we discover?
That kind of transparent iteration is what separates good governance from great governance.

Final Note:
Really appreciate the team taking a measured approach here rather than rushing the automatic solution. Shipping fast matters, but shipping right matters more.
Looking forward to the SNIP and happy to contribute feedback during the design phase :wolf:

8

Thanks for the thoughtful response!

On Communication Cadence:
You mention posting updates “in this thread at the community forum” every Thursday. Suggestion: also cross-post to Discord (#announcements) and Twitter for visibility. Not all builders actively monitor forums, but fee changes directly impact their bottom line.

I agree we should announce it further, it is also announced on TG (cairo core stars group) and several other groups (testnet mainnet production, starknet staking starting next time following feedback I got here). Adding discord is a great addition. Not sure including X is a must-have for awerness reason, and it might create an impression we think on fees much more than we actually do. Do you think visibility on X is crucial from the perspective of the SN developer?

Request: Could we get a simple dashboard (even a Dune Analytics query) showing:
∙ Current base fee (in STRK and $$ equivalent)
∙ Next scheduled adjustment date
∙ Historical base fee changes
This would help dApps budget accurately and reduce surprise factor.

“Next scheduled adjustment date” is unknown in advance, we don’t want to manually change base-fee by 1-2%. We are checking weekly, if price deviates by more than 10-20%-ish than the target 10^-9 for L2gas, manual change happens next (for example next Monday there would be no change unless price goes really crazy tomorrow and the day after, enough to take the 7 days average significnatly up/down). Having this $-target is also what should give predictability to builders

understand the rationale (avoid shocking users with sudden fee spikes), but I want to make sure this is communicated clearly to app developers.
If STRK price doubles overnight but fees take a week to gradually adjust upward, dApps get a temporary subsidy (paying less in real $$ terms). That’s great for them, but sequencers bear the cost.
As we move toward decentralized sequencing, we need community consensus on: who should absorb short-term volatility risk users/dApps or sequencers?
This manual phase is the perfect time to gather data and have that conversation before locking in the automatic mechanism.

In the automatic mechanism, adjustment will happen automatically, all the time, using embedded oracles. So these “few days discrepencies” will be avoided

You mention re-evaluating the $10^-9 baseline as protocol efficiency improves. Who decides when efficiency has changed enough to warrant adjustment?
Suggestion: Tie reevaluation to major protocol upgrades (e.g., post-hardfork, after prover improvements ship). This makes it predictable rather than subjective.
Bonus: Publish a “fee efficiency changelog” after each upgrade showing how L2gas costs have improved. This transparency builds trust and attracts cost-sensitive builders.

Indeed, this is a bit vague (also to me) ATM. Currently StarkWare operates the sole sequencer, taking all revenues and bearing all costs, but when we move to decentralized state we will need some hard-coded target which a governance process is dictating. Fee targets are delicate and reducing or increasing them has also economic aspects of “showing strength by collecting many fees” vs “encouraging growth” - so also long term we should avoid dynamic where some sequencers inflate this number to make profit or minority of the dApps aggressively pushing this down. I think this is an excellent topic for a Starknet-governance discussions and its important to align on how changes will be done here

9

Fair point on X - probably overkill for weekly checks. Too much fee talk might create impression of instability when it’s actually stable.

Discord is the key one imo. Most builders I see asking questions live there, not forums. TG works for core devs.

Compromise idea: only tweet when there’s an actual adjustment, skip the “we checked and no change needed” updates?

Either way, appreciate the thoughtfulness on comms frequency vs noise.