Key Takeaways
- What it is: Competition for the finite transaction capacity available in blocks.
- How it is built: Analysts combine block fullness, gas or weight usage, waiting transactions, fee distributions, inclusion delays, and failed activity.
- Core expression: Utilization = consumed block resource ÷ available block resource, interpreted with fee and queue conditions.
- Best use: Persistent high utilization plus rising fees suggests genuine congestion; full blocks with low fees may reflect protocol-specific capacity rules or subsidized demand.
- Main limitation: Mempools are node-local, private order flow is invisible, capacity changes over time, and different chains meter computation differently.
- Practical rule: Before treating full blocks or rising fees as congestion, confirm whether the capacity limit itself changed and whether the fee spike reflects genuine demand rather than protocol-specific subsidy or metering rules.
Who This Guide Is For
Block space is the one genuinely scarce resource a blockchain sells, and its price is set by an auction that runs every block. Read this page if you want to understand fee behavior from the supply and demand side rather than from a fee chart.
The construction section covers the units, which are the part most often skipped and most often the source of confusion: Bitcoin meters block space in weight units and Ethereum in gas, and neither is a byte count. The interpretation section covers why a chain can be full and cheap or empty and expensive.
Educational content. Not individualized financial advice.
What Does Block Space Demand Measure?
Block space demand measures how much of a chain's finite per-block capacity users are competing for, and what they are paying to win that competition. It has two halves that must be read together: a quantity, being how full blocks are, and a price, being what inclusion costs.
Neither half alone describes demand. Blocks are always full on a chain with a hard cap and persistent backlog, so fullness saturates and stops carrying information. Fee level alone confounds demand with capacity changes and with the pricing mechanism's own dynamics. The informative object is the pair, plus the backlog waiting outside the block.
Plain-language definition
Block space demand is how many transactions want into the next block versus how many fit, and what the ones that fit are paying.
Technical definition
Utilization is consumed capacity over available capacity per block, in the chain's own metering unit. The clearing price is the lowest fee rate included in a block, expressed per unit of that meter. Excess demand is the size of the pending queue, measured in the same units, which is the only one of the three that can express demand above the cap.
How Is Block Space Demand Constructed?
The metering unit differs by chain and is not a byte count on either major model.
Bitcoin: weight units
Since the SegWit upgrade, Bitcoin blocks are limited to 4,000,000 weight units rather than by raw byte size. Witness data is discounted relative to non-witness data, which means two transactions of identical byte length can consume different amounts of the cap depending on their structure. Fee rates are conventionally expressed in satoshis per virtual byte, where a virtual byte is a quarter of a weight unit.
Ethereum: gas
Ethereum meters computation and storage in gas, with each operation carrying a defined cost, so a block's capacity is a compute budget rather than a size limit. Under EIP-1559 each block carries a protocol-set base fee that is burned, adjusting automatically between blocks toward a target utilization, plus an optional priority fee paid to the proposer. The base fee mechanism means the price responds to sustained demand on its own rather than purely through user bidding.
EIP-4844 introduced a second, separate market for blob data used by rollups, metered and priced independently of execution gas. A chain can therefore have a congested execution market and a cheap blob market simultaneously, and reporting a single fee figure for the chain conflates them.
Build steps
- Choose the meter and state it. Weight units, virtual bytes, gas, or blob gas.
- Compute utilization against the actual protocol cap, not an assumed one.
- Record the clearing fee rate per block, not the mean fee paid, which is skewed by transactions that overbid.
- Capture pending-queue depth, which requires observing a node's own view and is not consensus data.
Formula and Measurement Logic
Utilization = consumed units ÷ maximum units per block
Clearing rate = minimum fee rate among included transactions
Excess demand = pending units above the clearing rate
The clearing rate is the important one and is routinely replaced by the average fee, which measures something else. The average includes transactions that bid far above what was necessary, so it rises when a few senders overpay even if the marginal cost of inclusion did not move. The minimum included rate is the actual price of block space.
| Quantity | Unit | What it captures | Failure mode |
|---|---|---|---|
| Utilization | Percent of cap | Whether blocks are full | Saturates at 100% and stops informing |
| Clearing rate | Fee per meter unit | Marginal price of inclusion | None major; the correct default |
| Average fee paid | Currency per transaction | Typical spend | Confounds fee rate with transaction size |
| Queue depth | Meter units pending | Demand above capacity | Node-local; not consensus data |
| Total fees | Currency per block | Revenue to proposers | Moves with token price, not demand |
Total fees denominated in currency is the least useful of the five for measuring demand, because a doubling of the token price doubles it with no change in how many people want block space.
How Should Block Space Demand Be Interpreted?
The four combinations of utilization and clearing rate describe four different chain states, and collapsing them into one fee chart loses the distinction.
| Low clearing rate | High clearing rate | |
|---|---|---|
| Blocks full | Ample low-value demand; capacity binding but nobody urgent | Genuine congestion; users competing for scarce inclusion |
| Blocks not full | Ample capacity; the normal quiet state | Structurally unusual; check for a minimum-fee floor or a mempool policy artifact |
Full blocks at a low clearing rate is the state most often misreported as congestion. It means the cap is binding but the marginal transaction is cheap, which is what a chain with persistent low-value automated activity looks like. Fee-sensitive users are unaffected.
Two structural points hold across chains. First, a chain with a hard cap and any persistent backlog will show near-100 percent utilization essentially always, so utilization is uninformative there and the clearing rate carries the whole signal. Second, demand is highly elastic: raising the cost of inclusion removes low-value activity quickly, so an observed drop in transaction count during a fee spike is a price response rather than a loss of users.
Step-by-Step Workflow
- State the chain's meter and its actual per-block cap.
- Use the clearing rate, the minimum included fee rate, rather than the average fee paid.
- Plot utilization and clearing rate together; neither is interpretable alone.
- Express fee rates in the meter unit, not in currency, when comparing across time.
- Separate execution and blob markets on chains that have both.
- Check whether the queue is a node-local view before treating backlog as a chain fact.
- Test whether a change in activity is a price response before calling it a demand change.
Worked Hypothetical Scenario
A chain reports these three days.
| Day | Utilization | Clearing rate | Avg fee paid | Transactions |
|---|---|---|---|---|
| 1 | 99% | 3 units | $0.42 | 640,000 |
| 2 | 99% | 61 units | $7.80 | 310,000 |
| 3 | 99% | 4 units | $3.10 | 620,000 |
Utilization is pinned at 99 percent all three days and tells you nothing. The clearing rate does all the work.
Day 2 is real congestion: the marginal transaction paid twenty times more than on day 1, and transaction count halved because low-value activity was priced out. That drop is a price response, not a loss of users.
Day 3 is the interesting case. The clearing rate has returned nearly to day 1 levels, so block space is cheap again, yet the average fee paid is seven times higher than day 1. That gap means a small number of senders were bidding far above the necessary rate, most likely large or urgent transactions overpaying. Anyone reading the average fee would report day 3 as still congested. It was not, and the clearing rate says so directly.
What Can Make the Interpretation Wrong?
- Utilization saturates. On a capped chain with any backlog it sits near 100 percent permanently and carries no information.
- Average fee is not the price of block space. It is skewed by overbidding and by transaction size. The clearing rate is the marginal price.
- Currency-denominated fees track the token price. A fee series in dollars measures the asset as much as it measures demand.
- Conflating separate fee markets. Execution gas and blob gas are priced independently, and one figure for the chain hides which is congested.
- Mempool is not consensus data. Queue depth is one node's view, differs between nodes, and depends on local relay policy.
- Weight is not bytes. Bitcoin's witness discount means byte-size intuitions give wrong capacity answers.
- Elastic demand read as lost users. Transaction count falling during a fee spike is the auction working as designed.
Cross-Network and Provider Comparison
The meter is chain-specific and does not convert, so cross-chain block space comparison requires care about what is actually being compared.
Bitcoin's cap is a fixed 4,000,000 weight units per block on a roughly ten-minute cadence, giving a stable and predictable supply of block space. Ethereum's gas limit is adjustable by validators within protocol bounds and meters computation rather than data, so two transactions of identical size can consume very different amounts of it. A megabyte of Bitcoin block space and a million gas of Ethereum capacity are not comparable quantities and no conversion between them is meaningful.
The pricing mechanisms differ as much as the meters. A pure first-price auction, where users bid and the highest bids are included, behaves differently from a mechanism with a protocol-set base fee that adjusts automatically toward a target utilization. Under the latter, sustained demand raises the price without users changing their bids, so a rising fee is not necessarily evidence of more aggressive bidding.
Rollups change the question entirely. A rollup buys base-layer data availability in bulk and resells execution to its users, so its users face a fee composed of a share of the base-layer cost plus the rollup's own charge. Base-layer block space demand and end-user cost are related but distinct on such a chain.
Advanced Analytical Methods
Fee-rate distribution within blocks
Publishing the full distribution of included fee rates rather than a single statistic shows how steep the auction was. A tight distribution means uniform urgency; a wide one means a few senders paid heavily for priority while most did not.
Demand curve estimation
Plotting clearing rate against included volume across many blocks traces an empirical demand curve for block space, which supports statements about elasticity that a time series alone cannot.
Separating durable from elastic demand
Comparing which transaction categories survive a fee spike identifies which activity is price-insensitive. Activity that persists at high clearing rates is the chain's durable demand; activity that vanishes is its elastic margin.
Base fee dynamics
On chains with an algorithmic base fee, the rate of change between blocks is bounded by protocol, so a step change in demand takes a predictable number of blocks to be priced in. Reading the base fee without accounting for that lag misattributes the adjustment path to changing demand.
Practical Checklist
- I stated the meter and the actual per-block cap.
- I used the clearing rate rather than the average fee paid.
- I plotted utilization and clearing rate together.
- I expressed fee rates in meter units rather than currency for time comparisons.
- I separated execution and blob fee markets where both exist.
- I noted that queue depth is a node-local observation.
- I checked whether an activity change was a price response.
- I did not convert one chain's meter into another's.
Frequently Asked Questions
Why is block utilization often uninformative?
On a chain with a hard cap and any persistent backlog, utilization sits near 100 percent essentially always. It saturates and stops varying, so it cannot distinguish a congested day from a quiet one. The clearing fee rate carries the signal instead.
What is the clearing rate and why use it instead of the average fee?
The clearing rate is the lowest fee rate among transactions included in a block, which is the actual marginal price of block space. The average fee paid is skewed upward by senders who bid far above what was necessary and by transaction size, so it can indicate congestion when block space is cheap.
How is Bitcoin block space measured?
Since SegWit, blocks are limited to 4,000,000 weight units rather than by raw byte size, with witness data discounted relative to non-witness data. Two transactions of identical byte length can therefore consume different amounts of the cap. Fee rates are conventionally quoted in satoshis per virtual byte, where a virtual byte is a quarter of a weight unit.
What does Ethereum gas actually meter?
Gas meters computation and storage, with each operation carrying a defined cost, so a block capacity is a compute budget rather than a size limit. Under EIP-1559 each block carries a protocol-set base fee that is burned and adjusts automatically between blocks toward a target utilization, plus an optional priority fee paid to the proposer.
Why do blob fees and gas fees need to be reported separately?
EIP-4844 introduced a second market for blob data used by rollups, metered and priced independently of execution gas. A chain can have a congested execution market and a cheap blob market at the same time, so a single fee figure for the chain hides which one is under pressure.
Is mempool backlog a property of the chain?
No. The pending queue is one node view of transactions it has received and chosen to relay. It differs between nodes and depends on local relay policy, so it is not consensus data and should not be reported as a chain-wide fact.
Do full blocks always mean congestion?
No. Blocks can be full at a very low clearing rate, which means the cap is binding but the marginal transaction is cheap. That is what a chain with persistent low-value automated activity looks like, and fee-sensitive users are unaffected. Congestion requires both full blocks and an elevated clearing rate.
How elastic is demand for block space?
Not uniformly, which is why fee spikes change the mix of activity as well as its level. Transactions carrying a large value or a time-sensitive purpose tolerate high fees, while small transfers and speculative activity are priced out quickly. A fee increase therefore reduces transaction counts more than it reduces value settled, and the surviving activity is systematically different from what preceded it. Any interpretation of a demand series through a fee spike has to account for that compositional shift rather than treating the drop as uniform.
How does a chain's block time affect the reading of utilization?
It sets the granularity of the measurement and the meaning of a full block. On a chain producing blocks every few seconds, one full block reflects a moment of demand and says little on its own. On a chain with blocks minutes apart, a single full block covers a much longer window and represents a more substantial backlog. Comparing utilization percentages across chains with different block intervals therefore compares averages taken over different periods, which is a common and unremarked source of misleading comparisons.
References
These sources should be reviewed during editorial verification. They support data structures and methods, not the hypothetical conclusion. Provider formulas, chain rules, and APIs can change. Confirm current documentation before publication.
- Ethereum.org: Transactions: Ethereum transaction fields and execution.
- Ethereum.org: Gas and Fees: Gas, base fees, tips, and block-space demand.
- Bitcoin Developer Guide: Transactions: UTXO transaction construction and spending.
- Coin Metrics: Transaction Metrics: Transaction-count definitions.
- Coin Metrics: New Addresses: New and funded address methodology.
- Coin Metrics: Network Data Glossary: Cross-network address, account, ledger, and UTXO definitions.
- Dune: Data Explorer and Raw Tables: Blocks, transactions, logs, traces, and decoded data.
- Dune: Curated Data Overview: Cross-chain normalized datasets.