Introduction
Starknet has operating costs on one hand and transaction fees on the other. Currently, the main goal of Starknetās transaction fee design is to cover operating costs without any profit at usersā expense. In this post we will explore the complexity around this design goal and how Starknet tackles it. For simplicity, we will focus on L1 costs throughout and disregard cloud costs.
The post is divided as follows: part I explains the complexity, while part II gives concrete formulas for Starknet fees vs costs as a function of system parameters and demand.
For the detailed cost structure and the formulas for costs vs fees, skip to part II.
Part I: design challenges
Covering operating costs without any profit means we aim to be at net zero margin. To that end, the obvious proposal is to charge each transaction a fee equal to its operating cost. So let us begin with a fundamental question: if the operating cost of a transaction is X, why not just charge it a transaction fee of X?
The answer is that some operating costs are not marginal: they are not derived from individual transactions. Instead these costs derive from Ethereum interaction, namely proof verification and state updates. Their key property is a fixed gas cost per action, independent of the very large number of Starknet transactions being compressed by Starknet. The proposal in the fundamental question covers marginal costs but neglects fixed costs, and is therefore refuted.
We arrive at a new task: design transaction fees to cover both marginal and fixed costs at a net zero profit. But how to distribute fixed costs over transactions? The key observation is that every action incurring a fixed cost is triggered by hitting some limiting system parameter. For example, past Starknet blocks were always closed due to reaching a compute limit. How does this observation help? Well, if fixed costs are always triggered by a compute limit then we can associate the fixed cost with a certain amount of compute units. This leads to a natural price per compute unit that would perfectly cover fixed costs: the fixed cost divided by the limit amount of computation. For example, if the total fixed cost is 100 gas, and each block is closed at a limit of 10 compute steps, then the compute fee should be 10 gas/step. Generalizing, we find the following principle: the cost per unit of the limiting resource equals the fixed cost divided by its limit amount. Since we aim for net zero profit, the fee per unit of the limiting resource should equal its cost. In essence, a limiting resource returns us to the marginal setting: each transaction should cover its ālimiting resource costā.
To summarize, we have arrived at the following proposal: the fee for a transaction should equal the sum of its marginal cost and its limiting resource cost. The journey appears complete: we have described a formula for transaction fees that covers operating costs at net zero profit. But alas, we come to a major hurdle:
 The limit amounts of various limiting resources are system parameters that often increase between Starknet versions: if we can batch more Starknet transactions per L1 operation then thereās no reason to wait for the next version ā itād just be a waste of resources. For example, increased block compute limits means that gas costs which are fixed per block are triggered after more computation than before.
 Such changes alter the cost per unit of the limiting resource.
 Transaction fee changes are coupled to Starknet versions, so the fee per unit cannot always match the cost per unit. Why the coupling? Because every fee change requires full node upgrades, and we want to minimize the resulting upgrade overhead.
The consequences of this disparity depend a lot on the demand for the limiting resources, which can lead to overcharging users or undercharging them (i.e operating losses).
Let us illustrate by example. Consider an intermediate block step limit increase between two Starknet versions, as in the following picture. Certainly the fee per step should be somewhere between the costs per step C/Lā and C/Lā. But where? If most of the demand comes before the increase, then the cost is dominated by the higher cost per step, whence the fee should be around C/Lā. On the other hand, if most of the demand comes after the increase, then cost is dominated by the lower cost per step, whence the fee should be around C/Lā.
We have seen how frequent changes to limit amounts vs infrequent changes to transaction fees introduce risk of nonzero net margin due to unpredictable demand. From here on there are two approaches to take:

A conservative approach, where fees are set to cover the current operating costs until the next version. In this approach, intermediate cost reductions are not transmitted to users until the next version. Hence, the system may enter a positive profit margin upon any intermediate cost reduction. In other words: users overpay.

A more useroriented approach, where fees are set to cover the estimated operating costs until the next version, taking intermediate cost reductions into account. This approach has the drawback of incurring risk on the Starknet operator: misestimations result in losses, and these estimations are no science!
 As we shall see in part II of the post, the unpredictability is exacerbated by the fact Starknet overcharges DA fees. We heuristically undercharge compute fees to counteract overcharging for DA.
 The misestimation risk is bounded by a very important dependence on demand: if resource limits are sufficiently high for full block fees to cover costs, then fees will cover costs given enough demand. In other words, assuming sufficiently high limits, enough TPS ensures transaction fees will cover operating costs.
Starknet takes the useroriented approach.
Part II: fee and cost formulas
Structure of operating costs
Marginal costs
Marginal, or pertx costs, are clearly mapped to individual transactions. The canonical almostexample is DA (data availability) costs: if a Starknet transaction writes to a storage cell in the state, it incurs an operating cost of sending this update to Ethereum. Here, cost is in units of Ethereum gas. Why almostexample then? Because many writes to a particular storage cell within the same Starknet block will still result in just one update to Ethereum: the final new value. The second example of marginal operating costs are those of handling L1/L2 messages.
Fixed costs
Nonmarginal costs, i.e ones that cannot be directly mapped to transactions, will be referred to as fixed costs. There are two granularities of fixed costs in Starknet: fixedperblock and fixedpertrain. Before recounting them, we should explain what a ātrainā is? A train is a batch of blocks that is jointly verified by a single STARK proof verification on Ethereum.
Fixed per SHARP train
The gas cost of verifying a proof of a train is fixed at a total of roughly 6M gas per train.
 3M gas
 8x Verify FRI
 3x Verify Merkle
 2M gas for execution of verifier ā part of Verify Proof and Register
 1M gas calldata for sending proof ā part of Verify Proof and Register
Fixed per Starknet block
There are several sources of fixedperblock costs, for a total of roughly 215K gas per block
 23K gas per fact registration ā part of Verify Proof and Register
 56K gas per SHARP memory page 0
 136K gas per State Update
Fee and cost formulas
The fee per block is given by the following formula, where ācspā is cairo step price, ādgpā is data gas price, and āgpā is gas price. The qualification of block user steps is meant to disregard steps that come from the Starknet operating system.
\begin{aligned}\text{fee per block} & = \text{csp}\times \text{block user steps}+\text{dgp}\times\text{block dg sold} \\ & =\text{gp}\times \underbrace{0.0025}_\text{gas per cs}\times \text{block user steps}+\text{dgp}\times\text{block dg sold} \end{aligned}
The cost per block is slightly more complex. The total amount of gas associated with a block is the sum of 215K fixedperblock that we have seen above and each blockās fractional part of the fixedpertrain gas. The previous sentence explained the first summand in the following formula. The second is simple: Ethereum transactions must pay for entire blobs, and Starknet the State Update transactions currently use at most one block.
\text{cost per block} = \text{gp}\times\frac{\text{gaspertrain}+\text{trainsize}\times \text{gasperblock}}{\text{train size}}+\text{blob price}
Before computing any numbers, note that Starknet transaction fees charge per write, but its DA costs depend only on the number of memory cells that were updated and not the number of updates to each. Thus Starknet overcharges its DA fees. Note moreover that this margin increases with blocksize, since multiple writes to the same cells are more likely to occur in larger blocks. Note it is possible to resolve DA overcharging by implementing a āDA refundā feature, as in zkSync. In the category of DA fee reduction features, we have prioritized volition over refunds as we believe volition will reduce both fees and costs more significantly. Moreover, volition will also reduce operating costs, unlike DA refunds.
Some numbers and breakeven conditions
After the 4844 upgrade, Starknet incurred operating losses. In the first week they were substantial, with over 8 ETH lost per day and less than 20% of costs covered by fees. Ever since, a gradual and ongoing improvement process is bringing costs down. Over the last 5 days the average net loss is <1.5 ETH per day, with fees covering over half the cost (82% on April 1). These improvements are underlain by two major factors:
 Block limits increase: the block step limit and blob data limit were both gradually increased. More resources per block increase the fees collected per block.
 Demand is implicit here: in addition to step and data limits, blocks also have a time limit. If demand is insufficient, then blocks will close due to time limits without containing many resources. If demand is low then the fees collected per will be low regardless of its resource limits.
 Data gas price increase, which amplifies the DA margin explained above. On March 28 Starknet was already covering half of its operating costs.
Here are some examples of fees vs costs with given parameters. The crucial factor is demand because it determines the amount of resources contained in a block. Resource prices are also crucial.
First, the current limits are 45M steps, a blobās worth of felts, and a lifespan of 6 minutes. Letās start with the following parameters, which are the average data over roughly 20 hours in the last few days.
\text{gp}=20\text{ gwei},\;\text{dgp}=60\text{ gwei},\;\text{block user steps}=22.5\text{M},\;\text{block dg sold}=128\text{K},\;\text{gas per block}=246\text{K},\;\text{train size}=192
we find that fees cover 69% of costs.
\begin{aligned}\text{fee per block} & = 8.8\text{M gwei} \\ \text{cost per block} & =12.8\text{M gwei} \\ \text{fee/cost per block} & = 0.69 \end{aligned}
In practice fees covered closer to 55% of costs, mainly because of a āfuturesā phenomenon: transaction fees are charged according to gas prices, but operating costs are only paid later at different gas prices. On this particular day, the fluctuations favored users, exacerbating losses.
Greater demand brings more steps and storage writes per block, as represented by the following parameters.
\text{gp}=20\text{ gwei},\;\text{dgp}=60\text{ gwei},\;\text{block user steps}=30\text{M},\;\text{block dg sold}=200\text{K},\;\text{gas per block}=246\text{K},\;\text{train size}=192
In this case we find that fees cover costs with a 6% margin!
\begin{aligned}\text{fee per block} & = 13.5\text{M gwei} \\ \text{cost per block} & =12.8\text{M gwei} \\ \text{fee/cost per block} & = 1.06 \end{aligned}
By configuring a longer block time, we can drive block resources even higher, but thatās a UX tradeoff we are constantly thinking about. As for gas and data gas prices, a ratio dgp/gpā3 seems reasonable when comparing the cost of a (nonzero) byte as 16 gas vs 1 data gas. Indeed a ratio of 3 means that blobs make DA 16/3ā5 times cheaper ā similar to the folklore estimates that have been floating around for months.
The tension between block frequency and L1 costs will be resolved by an upcoming feature called applicative recursion. It will both decouple block frequency from L1 costs and moreover reduce L1 costs further, allowing fees to cover costs. Read more about it here!