Effective Fee Rate

What Is the Effective Fee Rate?

The effective fee rate is the true fee rate at which a Bitcoin transaction will be prioritized for inclusion in a block. While the nominal fee rate is simply a transaction's fee divided by its virtual size, the effective fee rate accounts for relationships with other unconfirmed transactions. When a transaction has unconfirmed parents or children, miners must consider them together because Bitcoin consensus requires parent transactions to appear before their children in a block.

This distinction matters most in two scenarios: when a user creates a high-fee child transaction that spends an output from a low-fee parent (child pays for parent), or when fee estimation algorithms need to predict the actual cost of getting a transaction confirmed. In both cases, the nominal fee rate of any single transaction tells an incomplete story.

How It Works

Understanding the effective fee rate requires looking at how Bitcoin Core organizes and prioritizes unconfirmed transactions. The mempool is not a simple queue sorted by fee rate. It is a dependency graph where spending relationships between transactions create constraints on which transactions can be included together.

Nominal vs. Effective Fee Rate

The nominal fee rate is straightforward: divide the transaction's fee by its virtual size. For an isolated transaction with no unconfirmed parents or children, the nominal and effective fee rates are identical.

// Nominal fee rate (single transaction)
nominal_feerate = tx_fee / tx_vsize

// Example: 2,000 sat fee, 140 vB transaction
nominal_feerate = 2000 / 140 = 14.3 sat/vB

The effective fee rate diverges when a transaction has in-mempool relatives. Consider a parent transaction paying 1 sat/vB and a child paying 50 sat/vB. A miner wanting to collect the child's high fees must also include the parent, so the effective fee rate for the package is the combined fees divided by the combined virtual size:

// CPFP effective fee rate
parent: 200 sat fee, 200 vB → 1 sat/vB nominal
child:  7,500 sat fee, 150 vB → 50 sat/vB nominal

effective_feerate = (200 + 7500) / (200 + 150) = 22 sat/vB

Both transactions share this 22 sat/vB effective rate. The parent's effective rate is much higher than its nominal rate, while the child's is lower. Block explorers like mempool.space display effective fee rates rather than nominal ones, which is why a 1 sat/vB transaction can appear in a block where the minimum fee rate is far higher.

Ancestor and Descendant Fee Rates

Before the cluster mempool redesign, Bitcoin Core tracked two package-aware metrics for every mempool transaction:

• Ancestor fee rate: the sum of modified fees for the transaction and all its in-mempool ancestors, divided by their combined virtual size. Used for mining (block template construction).
• Descendant fee rate: the sum of modified fees for the transaction and all its in-mempool descendants, divided by their combined virtual size. Used for eviction decisions when the mempool is full.

// Ancestor fee rate (used for mining selection)
ancestor_feerate = sum(ancestor_fees) / sum(ancestor_vsizes)

// Descendant fee rate (used for eviction)
descendant_feerate = sum(descendant_fees) / sum(descendant_vsizes)

// Ancestor score (actual mining priority)
ancestor_score = min(individual_feerate, ancestor_feerate)

The ancestor score takes the minimum of the individual and ancestor fee rates. This ensures a high-fee transaction without low-fee ancestors is evaluated on its own merits rather than being diluted by the ancestor calculation.

You can inspect these values for any mempool transaction using the Bitcoin RPC:

bitcoin-cli getmempoolentry <txid>

# Returns ancestor/descendant fee data:
# "fees": {
#   "ancestor": 0.00015000,
#   "descendant": 0.00015000
# },
# "ancestorcount": 2,
# "ancestorsize": 350

Cluster Mempool: Chunk Fee Rates

The cluster mempool redesign, merged into Bitcoin Core in November 2025 and targeted for release in version 31.0, replaces the ancestor and descendant model with a more rigorous approach based on transaction clusters and linearization.

A cluster is a group of related transactions connected by spending relationships. The cluster mempool algorithm linearizes each cluster (sorts transactions topologically with parents before children), then partitions the linearization into consecutive groups called chunks. Each chunk has a monotonically decreasing fee rate: when consecutive transactions would form an increasing sequence, they are merged into a single chunk because a higher-fee transaction following a lower-fee one should always be included together.

// Chunk fee rate (cluster mempool)
chunk_feerate = sum(chunk_fees) / sum(chunk_vsizes)

// A transaction's "mining score" is its chunk fee rate
// This is the feerate at which it would enter a block template

This chunk-based model has a key advantage: mining and eviction become true inverse operations. Mining picks the highest-fee-rate chunks across all clusters; eviction removes the lowest-fee-rate chunks. The old system's ancestor/descendant asymmetry could sometimes evict high-value transactions or create inconsistencies in RBF evaluation. Under the cluster mempool, a transaction replacement is only accepted if the resulting mempool's feerate diagram is strictly better than before the replacement. For a deeper technical walkthrough, see the cluster mempool explainer.

Package Relay

Effective fee rate evaluation at the mining layer only works if transactions can actually reach miners as packages. Without package relay, a parent transaction below the node's minimum relay fee (typically 1 sat/vB) gets rejected outright, and the child that would bump it is also rejected because its parent input is unresolvable.

Bitcoin Core's one-parent-one-child (1p1c) package relay, deployed through a series of PRs in 2024 and 2025, solves this by allowing nodes to evaluate a parent-child pair together. If the combined package meets the minimum relay fee, both transactions are accepted into the mempool. This is particularly important for Lightning Network anchor outputs and other presigned contract protocols where the fee rate cannot be known at signing time. For more on this topic, see the v3 transactions and package relay guide.

Why It Matters

Fee Estimation Accuracy

Fee estimation algorithms must account for effective fee rates to avoid giving misleading recommendations. Bitcoin Core's estimator only tracks transactions that had no unconfirmed parents when they entered the mempool, specifically to avoid noise from CPFP chains. When a low-fee parent is confirmed only because of a high-fee child, the estimator excludes the parent from its dataset to prevent fee underestimation.

The cluster mempool enables better fee estimation because nodes can see the actual competitive ordering of transactions via chunk fee rates, rather than approximating through ancestor limits. For a comparison of estimation approaches, see the fee estimation algorithm comparison.

Fee Bumping Strategies

Understanding effective fee rate is essential for choosing between fee bumping strategies. With RBF, the replacement transaction's nominal fee rate is its effective rate (assuming no unconfirmed parents). With CPFP, the effective rate depends on the combined package, which means the child must pay enough to cover both transactions' combined virtual size at the target fee rate.

// How much fee does a CPFP child need?
target_rate = 20 sat/vB
parent_vsize = 200 vB
parent_fee = 200 sat (1 sat/vB)
child_vsize = 150 vB

// Required total fees for the package
required_total = target_rate * (parent_vsize + child_vsize)
               = 20 * 350 = 7,000 sat

// Child must pay the difference
child_fee = required_total - parent_fee
          = 7,000 - 200 = 6,800 sat

// Child's nominal rate: 6,800 / 150 = 45.3 sat/vB
// Package effective rate: 7,000 / 350 = 20 sat/vB ✓

This calculation shows why CPFP becomes expensive when the parent is large: the child must "pay for" the parent's entire virtual size at the target rate. For more on choosing between RBF and CPFP, see the fee bumping guide.

Layer 2 Protocol Design

Effective fee rate calculations are critical for Layer 2 protocols like Lightning, where transactions are presigned at channel open time but broadcast later when fee market conditions may have changed. Anchor outputs and v3 transactions (TRUC: topologically restricted until confirmation) are designed specifically to enable CPFP fee bumping for presigned commitment transactions, relying on package evaluation to ensure the effective fee rate meets current mempool conditions.

Off-chain protocols like Spark avoid on-chain fee rate concerns entirely for routine transfers: because Spark transactions settle off-chain, users are not exposed to mempool fee volatility. On-chain fees only become relevant during cooperative or unilateral exits back to the Bitcoin base layer.

Use Cases

• Wallet fee displays: showing users the true cost of confirming a transaction when unconfirmed parents exist, rather than a misleading nominal rate.
• Mining optimization: block template algorithms use effective fee rates (ancestor scores or chunk fee rates) to maximize the total fees collected per block.
• CPFP cost estimation: calculating how much a child transaction must pay to boost a stuck parent to a target confirmation priority.
• RBF comparison: determining whether replacing a transaction (RBF) or adding a child (CPFP) is more cost-effective given current mempool conditions.
• Mempool eviction policy: deciding which transactions to remove when the mempool approaches its size limit, using descendant or chunk fee rates to avoid evicting packages that include high-fee transactions.
• Lightning force-close fee management: ensuring commitment transactions with anchor outputs achieve sufficient effective fee rates through CPFP bumping when broadcast during high-fee periods.

Risks and Considerations

CPFP Cost Amplification

When using CPFP to bump a large parent transaction, the child's nominal fee rate must be significantly higher than the target effective rate. If the parent is 500 vB at 1 sat/vB and the target is 30 sat/vB, the child must pay for the parent's entire 500 vB "deficit" on top of its own fees. This makes CPFP increasingly expensive as parent transaction size grows, which is why RBF is often preferred when available.

Fee Estimation Lag

Fee estimation algorithms that ignore CPFP relationships may underestimate the true cost of confirmation. A block full of CPFP-bumped transactions appears to confirm low-fee transactions at face value, but the effective rates driving inclusion were much higher. Bitcoin Core's estimator mitigates this by filtering out CPFP-influenced data points, but third-party estimators may not apply the same correction.

Cluster Size Limits

The cluster mempool enforces a maximum cluster size of 64 transactions or 101 kB of virtual size. Transactions that would exceed these limits are rejected from the mempool, which can affect long unconfirmed transaction chains. This replaces the previous ancestor and descendant count/size limits (default 25 transactions or 101 kvB) with a single cluster-level constraint. The old CPFP carve-out exception, which allowed one additional descendant for two-party contracts, was removed in favor of v3/TRUC transaction rules.

Effective vs. Displayed Fee Rate

Different tools display fee rates differently. Some block explorers show nominal rates, others show effective rates, and not all make the distinction clear. When analyzing mempool conditions or reviewing confirmed transactions, verify which metric the tool reports. A transaction showing 2 sat/vB might have been confirmed at an effective rate of 25 sat/vB thanks to a high-fee descendant.

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.