Feerate Diagram

What Is a Feerate Diagram?

A feerate diagram is a graph that visualizes how much total fee a miner could collect by including transactions up to a given cumulative size from a mempool's linearization. The x-axis represents cumulative transaction size (in virtual bytes), and the y-axis represents the cumulative fee (in satoshis). Each point on the curve corresponds to the end of a chunk: a group of transactions from the linearization that share the same effective feerate. Between these points, the curve interpolates linearly.

The concept was formalized as part of Bitcoin Core's cluster mempool proposal, primarily by developer Pieter Wuille. Before cluster mempool, Bitcoin Core lacked a unified way to compare different mempool states and determine which one would produce better block templates for miners. The feerate diagram provides exactly this: a total ordering (or partial ordering) over mempool configurations that captures their relative value to miners.

The key mathematical property is concavity. A valid feerate diagram is the smallest concave function that sits at or above every prefix's fee-versus-size point. Because chunks are ordered by decreasing feerate, the curve bows upward: the steepest segments (highest-feerate chunks) come first, and the slope decreases as lower-feerate chunks are appended. This shape directly reflects how a rational miner would build a block, by including the highest-feerate transactions first.

How It Works

Constructing a feerate diagram begins with the linearization of a cluster. A cluster is a group of related (connected) mempool transactions. The linearization orders these transactions so that high-feerate subsets come first while respecting dependency (topological) constraints. Once linearized, the transactions are partitioned into chunks.

From Linearization to Chunks

Chunks are contiguous groups of transactions in the linearization where merging them yields a non-increasing sequence of feerates. Each chunk has a single effective feerate: its total fee divided by its total size. The chunking process works as follows:

1. Start with each transaction as its own chunk, ordered according to the linearization
2. Walk through the sequence and compare adjacent chunks: if a later chunk has a higher feerate than the preceding one, merge them into a single chunk
3. Repeat until no adjacent pair violates the non-increasing feerate property

The result is a partition of the cluster into chunks with strictly non-increasing feerates. These chunks are the building blocks of the feerate diagram.

Plotting the Diagram

Each chunk contributes one line segment to the diagram. Starting from the origin (0, 0), the first chunk extends the curve to the point (chunk_size, chunk_fee). Each subsequent chunk adds its size and fee to the running totals. In pseudocode:

# Build feerate diagram from chunks
cumulative_size = 0
cumulative_fee = 0
points = [(0, 0)]

for chunk in chunks_sorted_by_feerate_descending:
    cumulative_size += chunk.size
    cumulative_fee += chunk.fee
    points.append((cumulative_size, cumulative_fee))

# The resulting curve is concave:
# slope of each segment = chunk.fee / chunk.size
# slopes are non-increasing

The slope of each line segment equals the feerate of the corresponding chunk. Because chunks are ordered by decreasing feerate, the slopes form a non-increasing sequence, which guarantees the concave shape.

Comparing Two Diagrams

The primary purpose of feerate diagrams is comparison. Given two mempool states (for example, the current mempool versus a proposed replacement), their feerate diagrams can be compared point-by-point:

• Diagram A is "at least as good as" Diagram B if, for every cumulative size value, A's cumulative fee is greater than or equal to B's cumulative fee
• Diagram A is "strictly better" than Diagram B if A is at least as good as B, but B is not at least as good as A (meaning A is strictly higher at at least one point)
• Two diagrams are "incomparable" if neither is at least as good as the other: each diagram is higher in some regions and lower in others

This comparison defines a partial ordering over mempool states. Not every pair of states can be ranked, which is an important property: it prevents the system from accepting replacements that help one part of the mempool while harming another.

Use Cases

Incentive-Compatible RBF

The most significant application of feerate diagrams is improving replace-by-fee (RBF) policy. Under the legacy BIP 125 rules, a replacement transaction had to pay a higher absolute fee than the sum of all transactions it displaced and cover the minimum relay fee for its own size. These rules could produce perverse outcomes: a replacement might pay more total fee but have a lower feerate, meaning miners would actually prefer the original transactions for block inclusion.

With feerate diagrams, Bitcoin Core can evaluate whether a replacement genuinely improves the mempool from a miner's perspective. A replacement is accepted only if the resulting mempool's feerate diagram is strictly better than the current one. This ensures that every accepted replacement increases the total fee a miner would collect at every possible block size threshold, not just in aggregate. For deeper analysis, see the cluster mempool deep dive.

Block Template Construction

The feerate diagram directly informs how miners build block templates. The optimal strategy is straightforward: include chunks from highest feerate to lowest feerate across all clusters until the block is full. This is equivalent to filling the block by tracing the feerate diagram from left to right, always selecting the steepest available segment.

Because chunks represent indivisible units for template purposes (splitting a chunk would violate topological ordering), the block template may not perfectly fill the block size limit. This bin-packing effect at the tail end of the block is a known limitation that the feerate diagram does not capture.

Mempool Eviction

When the mempool exceeds its size limit, nodes must evict transactions. The feerate diagram guides this decision by identifying the lowest-value transactions: eviction removes the lowest-feerate chunks (the rightmost, flattest segments of the diagram) first. This is the mirror image of block building: building selects from the left (highest feerate), while eviction removes from the right (lowest feerate).

Why It Matters

Before the feerate diagram framework, Bitcoin Core's mempool policies relied on heuristic rules that could be gamed or could produce suboptimal outcomes. The ancestor-feerate-based mining algorithm and the BIP 125 replacement rules operated on different models of transaction priority, leading to inconsistencies. A transaction could be accepted as a "better" replacement under RBF rules while actually producing a worse block template.

Feerate diagrams unify these operations under a single mathematical framework. Block building, eviction, and replacement all reference the same curve, ensuring consistency. When a replacement improves the diagram, it improves the block template by definition. When an eviction removes the diagram's tail, it removes the least valuable transactions by definition.

For Bitcoin's fee market, this matters because miners can trust that their mempool policies are aligned with revenue maximization. Users benefit because fee-bumping strategies like RBF produce predictable results: a higher-feerate replacement will always be accepted if it genuinely improves the mempool.

Layer 2 protocols also benefit. Networks like Lightning and Spark depend on timely on-chain settlement of commitment and penalty transactions. Predictable fee-bumping behavior, grounded in the feerate diagram model, gives these protocols stronger guarantees that their transactions will be included when needed.

Risks and Considerations

Partial Ordering Limitations

Because feerate diagram comparison is a partial ordering, some replacement proposals are "incomparable": neither strictly better nor strictly worse. In these cases, the replacement is rejected, even if it might arguably improve the mempool in some dimensions. This conservatism prevents certain valid replacements from being accepted but avoids the risk of making the mempool worse from a miner's perspective.

Bin-Packing at the Block Boundary

The feerate diagram measures quality at the chunk level, but block templates have a hard size limit. The last few chunks may not fit cleanly within the remaining block space, and the diagram does not account for this tail effect. Two diagrams that appear identical at the chunk level could produce different actual block revenues depending on how their chunks fit the remaining space.

Computational Complexity

Constructing optimal linearizations (which produce the best possible feerate diagrams) is computationally expensive for large clusters. Bitcoin Core mitigates this by limiting cluster size and using bounded-search algorithms that find good (though not always optimal) linearizations. The default limits in Bitcoin Core cap clusters at 101 kvB in size and 64 transactions.

Sensitivity to Linearization Quality

The quality of the feerate diagram depends entirely on the quality of the underlying linearization. A suboptimal linearization produces a feerate diagram that understates the mempool's true value. Two implementations using different linearization algorithms could produce different feerate diagrams for the same set of transactions, leading to divergent replacement and eviction decisions.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.