Skip to content
Financial Context Wiki

Blob fees and rollup costs

A verification-first guide to Ethereum blob gas, current blob schedules, batch utilization, rollup fee allocation and the difference between L1 posting cost and an L2 user's bill.

Updated

For educational purposes only; not financial or security advice. Blob parameters, rollup fee formulas, sequencer policies, exchange rates and data-availability assumptions can change or fail.

Direct answer

An Ethereum blob fee is the protocol charge for publishing blob data, not the complete fee paid by an L2 user. A blob-carrying transaction pays blob_count * 131,072 * blob_base_fee_per_blob_gas for blob gas and separately pays ordinary execution gas. A rollup may then allocate that L1 cost through its own compression, scalar, overhead and operator-pricing rules, so the batch submitter’s receipt, the rollup’s cost estimate, the user’s quote and the operator’s revenue are different records.

Blobs are temporary data sidecars committed by versioned KZG hashes. The EVM can use the commitments but cannot read the blob bytes directly. PeerDAS changes how Ethereum nodes distribute and sample that data; it does not turn blobs into permanent archives or make one rollup’s user-fee formula universal. Capacity is also fork-dependent. As of 2026-08-13, Ethereum mainnet after Fusaka BPO2 targets 14 blobs and permits at most 21 blobs per block, replacing the earlier 3/6 and 6/9 schedules.

How it works

  1. Pin the measurement context: Ethereum network, block or slot, active fork and Blob-Parameter-Only schedule, rollup deployment and fee-formula version, L1 origin, user fee token and exchange-rate timestamp. Never apply current mainnet parameters to an old block, testnet or future fork.
  2. Identify the posting object from chain evidence. Record the type-3 transaction, sender, receipt, versioned hashes, blob count, blob_gas_used, encoded and usable payload bytes, compression or framing and whether the rollup used blobs, calldata or another data-availability path.
  3. Read both fee markets. Blob gas uses 131,072 blob gas per blob; distinguish the realized blob_base_fee_per_blob_gas from the sender’s max_fee_per_blob_gas cap. Separately record execution gas used, effective execution-gas price and priority fee. After EIP-7918, low blob pricing has a reserve-price relationship to execution cost even though the two resources retain separate accounting.
  4. Reconstruct the batch submitter’s actual L1 ledger: blob fee burned, execution fee and tip, plus matched state-output, proof, bridge or posting transactions. A blob fee is charged even when the blob transaction’s execution fails, and a fee cap that was not charged is neither cost nor a refund.
  5. Reproduce the specific rollup’s current attribution formula. Record compressed bytes or another metered unit, scalars, fixed overhead, operator or priority charges, refunds and fallback rules. OP Stack documentation can evidence an OP deployment only; another rollup may allocate costs differently.
  6. Keep four ledgers separate: batcher L1 cost, rollup-attributed L1 data cost, actual user debit and operator revenue or margin. Equal division by transaction count is only an analytical allocation. Batch fill, padding, transaction mix, delayed posting and cross-subsidy can make it differ from the protocol’s quote.
  7. Reconcile against receipts and stress the result. Test blob-price spikes, execution congestion, ETH and fee-token FX, low batch utilization, sequencer delay, calldata fallback, formula upgrades, L1 reorganization, temporary data retention and archive failure. Report the block, units, assumptions and unmatched costs with every per-user figure.

Worked examples

  • Protocol blob charge. Two blobs consume 2 * 131,072 = 262,144 blob gas. At 30 gwei per blob gas, the fee is 262,144 * 30 * 10^-9 = 0.00786432 ETH. At $2,500 per ETH, that is $19.6608. This excludes the blob transaction’s ordinary execution fee.
  • Two fee ledgers on one transaction. If the same type-3 transaction uses 120,000 execution gas at an effective 22 gwei, execution costs 120,000 * 22 * 10^-9 = 0.00264 ETH. Total L1 charge is 0.00786432 + 0.00264 = 0.01050432 ETH, or $26.2608 at the stated FX rate. Blob gas and execution gas remain distinct inputs.
  • Batch utilization and allocation. Add $4.0000 of matched proof and posting cost, making the analytical batch cost $30.2608. Across 2,000 included transactions, equal-count allocation is $30.2608 / 2,000 = $0.0151304 per transaction; across only 800, it is $30.2608 / 800 = $0.0378260. Neither number is automatically the user’s quote or the operator’s realized margin.
  • Current capacity and byte units. With the date-specific 14/21 schedule, target and maximum are 14 * 131,072 = 1,835,008 and 21 * 131,072 = 2,752,512 blob-gas units, corresponding to 1.75 MiB and 2.625 MiB of encoded blobs. Because arbitrary payload generally uses 31 bytes in each 32-byte field element, usable payload is 14 * 126,976 = 1.6953125 MiB at target and 21 * 126,976 = 2.54296875 MiB at maximum, before compression and framing.

Risks

  • Applying a stale fork or Blob-Parameter-Only schedule.
  • Mixing mainnet, testnet or another chain’s blob parameters.
  • Confusing blob gas, execution gas, encoded bytes and usable bytes.
  • Treating max_fee_per_blob_gas as the realized base fee.
  • Omitting the type-3 transaction’s ordinary execution fee and tip.
  • Assuming failed execution refunds the charged blob fee.
  • Using a stale RPC estimate instead of the included block and receipt.
  • Crossing a fee change while a sequencer delays batch publication.
  • Underestimating a blob-congestion spike or reserve-price behavior.
  • Ignoring L1 execution congestion because blob gas is cheap.
  • Allocating underfilled or padded batches as if they were full.
  • Using the wrong compression, framing or transaction-mix assumption.
  • Double-counting proof, state-output, bridge or posting transactions.
  • Applying a stale rollup scalar, overhead or operator-fee formula.
  • Confusing a user quote, actual debit, refund and operator revenue.
  • Triggering expensive calldata fallback or a different DA security model.
  • Converting ETH and fee tokens with the wrong price or timestamp.
  • Losing or misattributing a batch after replacement or L1 reorganization.
  • Treating temporary PeerDAS availability as permanent archival retrieval.
  • Ignoring sequencer, validity, finality, bridge or exit failure because blobs were available.

Common misconceptions

  • The blob base fee is the whole L2 fee paid by a user.
  • max_fee_per_blob_gas is the amount actually charged.
  • All 131,072 encoded bytes in a blob are arbitrary user payload.
  • A lower blob base fee immediately reduces every L2 user’s fee by the same percentage.
  • Blob data are permanently stored inside the EVM and every rollup uses fixed 3/6 or 6/9 capacity.

Sources

Navigation

Search the wiki...