# How Bitcoin Core's Fee Estimation Algorithm Works: A Deep Dive into Statistical Confirmation Modeling

> Uncover how Bitcoin Core's fee estimation algorithm works. Learn about its statistical, bucket-based approach for predicting transaction confirmation likelihood from mempool data.

- Repository: [Bitcoin/bitcoin](https://github.com/bitcoin/bitcoin)
- Tags: deep-dive
- Published: 2026-02-28

---

**Bitcoin Core's fee estimation algorithm is a statistical, bucket-based estimator that learns from real-world transaction confirmations by aggregating mempool data across exponentially-spaced feerate buckets and three independent time horizons to predict confirmation likelihood.**

Bitcoin Core's fee estimation algorithm continuously monitors the mempool to provide adaptive transaction fee recommendations without relying on hard-coded heuristics. This statistical system tracks when transactions enter the mempool and how many blocks they require for confirmation, storing this data in [`src/policy/fees/block_policy_estimator.cpp`](https://github.com/bitcoin/bitcoin/blob/main/src/policy/fees/block_policy_estimator.cpp). The algorithm powers the `estimatesmartfee` RPC and wallet fee calculations, returning estimates based on historical confirmation probabilities.

## How the Fee Estimation Algorithm Tracks Transactions

The foundation of the fee estimation algorithm lies in **feerate buckets** that group transactions by their fee-per-byte rate. In [`src/policy/fees/block_policy_estimator.h`](https://github.com/bitcoin/bitcoin/blob/main/src/policy/fees/block_policy_estimator.h), the estimator defines exponentially-spaced buckets with approximately 1.05 spacing, ranging from `MIN_BUCKET_FEERATE` (100 sat/kB) to `MAX_BUCKET_FEERATE` (10,000,000 sat/kB).

When a transaction enters the mempool, `TxConfirmStats::NewTx` records its bucket index and the current block height. The algorithm maintains a circular buffer called `unconfTxs` that tracks how many transactions remain unconfirmed for each bucket and confirmation age. As implemented in [`src/policy/fees/block_policy_estimator.cpp`](https://github.com/bitcoin/bitcoin/blob/main/src/policy/fees/block_policy_estimator.cpp), this structure enables efficient tracking of transaction lifecycles without storing individual transaction data.

## Time Horizons and Decay in the Fee Estimation Algorithm

To balance recent market conditions against long-term trends, the fee estimation algorithm maintains **three independent statistical horizons**:

- **Short-term**: 0.962 decay per block
- **Medium-term**: 0.9952 decay per block  
- **Long-term**: 0.99931 decay per block

Each horizon applies exponential decay to its confirmation counters via `TxConfirmStats::UpdateMovingAverages`, ensuring that recent data dominates short-term estimates while older data still informs long-term trends. When processing a new block, `TxConfirmStats::Record` increments confirmation counters for all buckets up to the number of periods (`scale`) that have passed.

## The Three Success Thresholds

When `CBlockPolicyEstimator::estimateSmartFee` receives a confirmation target request, it evaluates **three distinct success probabilities** to ensure reliability:

1. **HALF_SUCCESS_PCT (60%)**: Transactions must show a 60% confirmation rate within *target ÷ 2* blocks
2. **SUCCESS_PCT (85%)**: Transactions must show an 85% confirmation rate within the *target* blocks
3. **DOUBLE_SUCCESS_PCT (95%)**: Transactions must show a 95% confirmation rate within *2 × target* blocks

The algorithm returns the **highest feerate** that satisfies all three thresholds simultaneously. This multi-tiered approach prevents underestimation during volatile mempool conditions by requiring consistent confirmation performance across different time windows.

## Conservative Estimates and Median Calculation

For users requiring higher certainty, the algorithm supports a **conservative mode** that enforces the 95% success threshold (`DOUBLE_SUCCESS_PCT`) at *2 × target* across **all three horizons**, not just the selected one. This prevents short-term mempool spikes from artificially lowering estimates when stability is required.

The actual fee calculation occurs in `TxConfirmStats::EstimateMedianVal`, which merges adjacent bucket ranges until sufficient sample size exists (`SUFFICIENT_FEETXS` ≈ 0.1 transactions per block). The function returns the **median feerate** of the best bucket range meeting the required success probability, providing a robust statistical center rather than an average that could be skewed by outliers.

## Source Code Implementation of the Fee Estimation Algorithm

The fee estimation algorithm spans several key files in the repository:

- [`src/policy/fees/block_policy_estimator.h`](https://github.com/bitcoin/bitcoin/blob/main/src/policy/fees/block_policy_estimator.h): Declares `CBlockPolicyEstimator`, `TxConfirmStats`, bucket structures, and constants including `HALF_SUCCESS_PCT`, `SUCCESS_PCT`, and `DOUBLE_SUCCESS_PCT`
- [`src/policy/fees/block_policy_estimator.cpp`](https://github.com/bitcoin/bitcoin/blob/main/src/policy/fees/block_policy_estimator.cpp): Implements the full estimation logic including data collection, decay calculations, and the three-threshold evaluation
- [`src/rpc/fees.cpp`](https://github.com/bitcoin/bitcoin/blob/main/src/rpc/fees.cpp): Exposes `estimatesmartfee` and legacy `estimatefee` RPC endpoints
- [`src/wallet/fees.h`](https://github.com/bitcoin/bitcoin/blob/main/src/wallet/fees.h) and [`src/wallet/fees.cpp`](https://github.com/bitcoin/bitcoin/blob/main/src/wallet/fees.cpp): Wallet-level helpers that interface with the node's estimator

## Using the Fee Estimation Algorithm in Practice

### RPC Command

The most common interface to the fee estimation algorithm is the `estimatesmartfee` RPC command:

```bash

# Request a fee estimate for confirmation within 6 blocks

bitcoin-cli estimatesmartfee 6

```

Typical response:

```json
{
  "feerate": 0.00001500,
  "blocks": 6,
  "decay": 0.9952,
  "reason": "FULL_ESTIMATE"
}

```

### Direct C++ Integration

To call the estimator programmatically from within Bitcoin Core:

```cpp
#include <policy/fees/block_policy_estimator.h>
#include <rpc/server_util.h>

// Assuming NodeContext is available
CBlockPolicyEstimator& estimator = EnsureFeeEstimator(node);

int target = 4;
FeeCalculation calc;
CFeeRate fee = estimator.estimateSmartFee(target, &calc, /*conservative=*/false);

// fee.GetFeePerK() returns the estimate in satoshis per kilobyte
// calc.reason contains HALF_ESTIMATE, FULL_ESTIMATE, DOUBLE_ESTIMATE, or CONSERVATIVE

```

### Advanced Statistical Access

For direct access to bucket statistics:

```cpp
// Accessing TxConfirmStats directly for custom analysis
int target = 10;
double success_threshold = 0.85;
unsigned int current_height = 750000;
EstimationResult result;

double median_feerate = stats->EstimateMedianVal(
    target, 
    TxConfirmStats::SUFFICIENT_FEETXS,
    success_threshold, 
    current_height, 
    &result
);

```

## Summary

- Bitcoin Core's fee estimation algorithm uses **exponentially-spaced feerate buckets** from 100 sat/kB to 10M sat/kB to categorize mempool transactions
- The system maintains **three time horizons** with different decay rates (0.962, 0.9952, 0.99931) to weight recent vs. historical data
- Estimates require satisfying **three success thresholds**: 60% at half-target, 85% at target, and 95% at double-target blocks
- **Conservative mode** enforces the 95% threshold across all horizons for maximum reliability, returning the highest fee that meets all requirements
- The implementation resides in [`src/policy/fees/block_policy_estimator.cpp`](https://github.com/bitcoin/bitcoin/blob/main/src/policy/fees/block_policy_estimator.cpp) and exposes via `estimatesmartfee` RPC

## Frequently Asked Questions

### What are the three success thresholds used in Bitcoin Core's fee estimation algorithm?

The algorithm evaluates three confirmation probabilities: **HALF_SUCCESS_PCT (60%)** requiring confirmation within target ÷ 2 blocks, **SUCCESS_PCT (85%)** requiring confirmation within the target blocks, and **DOUBLE_SUCCESS_PCT (95%)** requiring confirmation within 2 × target blocks. The estimator returns the highest feerate that satisfies all three thresholds simultaneously, ensuring robustness across different confirmation timeframes.

### How do the three time horizons affect fee estimates?

Bitcoin Core maintains independent statistics for **short-term** (0.962 decay), **medium-term** (0.9952 decay), and **long-term** (0.99931 decay) horizons. When estimating fees, the algorithm selects the shortest horizon capable of covering the requested target. The short horizon reacts quickly to recent mempool changes, while the long horizon provides stability during transient fluctuations.

### What distinguishes conservative mode from standard fee estimates?

**Conservative mode** requires the 95% success threshold (`DOUBLE_SUCCESS_PCT`) to be met at double the target blocks across **all three horizons** (short, medium, and long), whereas standard estimates only check the selected horizon. This prevents temporary mempool lulls from generating underestimates but typically returns higher feerates than the standard economic mode.

### How are feerate buckets structured in the estimator?

The estimator uses **exponentially-spaced buckets** with approximately 1.05 spacing between adjacent buckets, spanning from `MIN_BUCKET_FEERATE` (100 sat/kB) to `MAX_BUCKET_FEERATE` (10,000,000 sat/kB). Transactions are sorted into these buckets upon mempool entry via `TxConfirmStats::NewTx`, and confirmation statistics are aggregated per-bucket rather than tracking individual transactions.