Blob fees vs L2 gas: read the cost breakdown

Ethereum blob fees pay for blob data published to Ethereum, while L2 execution gas pays for computation on a rollup. A user's L2 fee can include execution, a charge toward L1 data publication and chain-specific additions. These are different ledgers: the batch poster's Ethereum bill is not automatically the amount charged to one L2 user. Check the rollup's active fee rules and units before adding components.

A low blob-price reading does not establish that your next swap will be cheap. The transaction may perform substantial L2 work, its data charge may use an estimator, and the wallet may combine several components under one label. To understand a quote, first identify whose bill it describes and which resources the number prices.

Follow the payer through both layers

A rollup can collect many L2 transactions and publish their compressed data together on Ethereum. With blob publication, distinguish the Ethereum transaction that posts that data from each user's transaction inside the rollup.

EIP-4844 defines blob gas separately from ordinary execution gas. Each blob accounts for 131,072 blob-gas units, and the blob charge is those units multiplied by the blob base fee. The blob-carrying transaction also has ordinary execution-fee fields. Publishing a batch therefore has a data charge and an execution charge on Ethereum.

That per-blob quantity does not specify the current target or maximum blobs per block. EIP-7840 puts those capacity parameters in a schedule for each fork.

The first two rows belong to the poster's bill. The next rows describe the user's bill. Adding every row together would mix payers and count data funding twice.

Blob data also serves a different purpose from running a user's contract call. EIP-4844 exposes versioned hashes of blob commitments to EVM execution while the blob bytes themselves are not directly accessible to it. Paying to publish a batch does not replace the computation needed to execute its transactions on L2. Cheap publication alone cannot make that computation free.

Reconcile a hypothetical batch with one user's charge

Consider an entirely fictional rollup that posts two blobs in one Ethereum transaction. All prices, gas usage and the allocation policy below are invented for arithmetic; they are not current network quotations or a production rollup's fee formula.

Assume the posting transaction consumes 50,000 L1 execution-gas units at an effective price of 12 gwei per unit. Its blobs cost 2 gwei per blob-gas unit. Two blobs account for 262,144 blob-gas units.

Use consistent currency conversions. As Ethereum's gas documentation explains, one gwei is one billion wei, or one-billionth of an ETH. A gas quantity is not itself an ETH amount: multiply it by the matching price first.

For this post hoc teaching calculation, stipulate that the fictional rollup divides its complete posting bill into 1,000 equal posting shares. The user in our example pays one share. This is a deliberate simplification; transaction count is not a measurement of compressed data contribution or a way to quote an unknown future posting bill.

One share is 0.000001124288 ETH. Separately, the user's L2 transaction consumes 150,000 execution-gas units at 0.02 gwei per unit, giving 3,000 gwei, or 0.000003 ETH. Add an invented fixed operator charge of 0.0000004 ETH.

There are two reconciliation checks. All 1,000 allocated shares sum to the poster's 0.001124288 ETH bill. The individual user's three charges sum to 0.000004524288 ETH. The poster total is context for the allocation, not another amount to add to this user's total.

At an invented display conversion of $2,500 per ETH, the poster bill is $2.81072 and the user charge is $0.01131072. Preserve the native amounts before rounding dollar displays. Rounding each tiny component to cents first would destroy useful information.

This example also isolates sensitivity. Double only the blob price from 2 to 4 gwei. The poster bill becomes 0.001648576 ETH, and the same equal-allocation policy makes the user total 0.000005048576 ETH. The user's bill rises about 11.59%, rather than doubling, because L1 submission execution, L2 execution and the fixed charge are unchanged in this scenario.

That result is a property of these inputs. A transaction with a different data share or more expensive execution would respond differently.

Real rollups price the allocation differently

An equal split is useful for checking a ledger, but actual data pricing must work before the final batch bill is known. Arbitrum's gas-and-fee explanation describes the difficulty: batch composition, compression and the future posting price are uncertain when a transaction is sequenced. Its documented model uses an estimated transaction footprint and an adaptive data price.

This means a user's data charge should not be reverse-engineered by dividing one visible batch invoice by its transaction count. Even a perfectly recorded later invoice does not establish the estimator and policy used when the user was charged. Keep those two observations as separate evidence.

For ordinary sequenced user transactions, OP Mainnet's fee documentation describes execution fees, an L1 data fee and an operator fee after Isthmus. Deposit transactions are exempt from the operator fee. Its documented Fjord model estimates compressed size with FastLZ and applies chain scalars to L1 base and blob-base-fee inputs. The operator formula differs under the documented Jovian upgrade. Record the active fork and configuration before applying a saved formula.

A second difference concerns presentation. Arbitrum's gas-estimation guide explains that its parent-chain cost can be converted into an extra buffer expressed in L2 gas units. The total estimate includes that buffer; NodeInterface.gasEstimateComponents() exposes a breakdown. A larger displayed gas estimate can therefore reflect data pricing as well as computation. Adding a separately displayed data estimate to an already inclusive total would count it twice.

Finally, separate accounting does not mean fully disconnected price dynamics. EIP-7918 specifies a reserve-price condition tied to L1 execution base fees in the blob-base-fee update mechanism. Check the chain's active fork before applying that rule. It does not turn blob gas into L2 execution gas. Avoid assuming either that every price moves together or that the markets have no linkage.

Investigate a wallet quote that looks inconsistent

Start by comparing the same transaction, network and observation time. A simple transfer and a complex swap are different workloads. A quote taken before congestion changed and an included transaction observed later are different price observations. Save enough information to distinguish a changed action from changed prices.

Then check these failure cases:

• The dashboard shows only blob prices. Obtain the L2 execution estimate and all other applicable charges. A data-price dashboard answers one part of the question.
• Two values use the same currency label but different denominators. Gwei per blob, per blob-gas unit and per execution-gas unit are different prices. Write the denominator beside each input before multiplying.
• An inclusive total is treated as an execution subtotal. Check the network's estimator and explorer definitions. Mark a data component as embedded when it already belongs to the displayed total.
• The wallet maximum becomes the booked expense. Retain the quote and funding ceiling, then reconcile actual charges after inclusion. A ceiling and a settled fee serve different purposes.
• The transaction failed, so its cost is omitted. Check inclusion and the actual outcome before assigning a charge. The failed-swap gas ledger provides a detailed method for distinguishing included reverts, pending attempts and confirmed replacements.

For smart-account activity, also identify which account ultimately pays. The UserOperation-versus-transaction guide helps separate the user's requested action from the transaction submitted around it. A balance change in one account may not describe the entire operation's cost.

Keep transfers between networks in their own scope. A withdrawal may involve several transactions or a separate service quote. Use the canonical-withdrawal-versus-fast-bridge comparison to examine that journey before treating one L2 fee as its complete budget.

Keep a worksheet that can be checked later

For each activity, save a quoted estimate and a final record. The final record should state which amounts are directly observed and which remain estimates. An unexplained residual is a reason to inspect the model, not a license to assign the difference to blobs.

For a recurring operation, roll these records into a cost per completed intention, including separately chargeable attempts within the declared scope. Preserve unresolved attempts as unresolved. The trading-bot total-cost worksheet then places reconciled transaction charges beside software and operating expenses.

Close each fee record with one native-currency total, a clear payer and an explanation of every included component. That makes the next comparison actionable: you can identify whether a higher bill came from data pricing, L2 work, an added charge or a different transaction scope.