Minimum Relay Fee

What Is the Minimum Relay Fee?

The minimum relay fee (configured via the -minrelaytxfee parameter in Bitcoin Core) is the lowest fee rate a node will accept when deciding whether to add an unconfirmed transaction to its mempool and forward it to other nodes on the peer-to-peer network. Any transaction paying below this rate is rejected outright: it will not enter the node's mempool and will not be relayed further.

This threshold exists primarily as a DoS protection mechanism. Without it, an attacker could flood the network with zero-fee or near-zero-fee transactions, consuming bandwidth, CPU cycles, and memory across thousands of nodes at virtually no cost. By requiring every transaction to pay a minimum price per unit of block space, the relay fee creates a cost floor for using the network's relay infrastructure.

Critically, the minimum relay fee is a policy rule, not a consensus rule. Miners are free to include any valid transaction in a block regardless of its fee rate. However, if no node on the network will relay a low-fee transaction, it will never reach miners in the first place: unless it is submitted directly to a miner's node.

How It Works

When a Bitcoin node receives a new transaction (either from a wallet via RPC or from a peer), it checks the transaction's fee rate against the configured minimum relay fee. The fee rate is measured in satoshis per virtual byte (sat/vB), which accounts for the SegWit witness discount.

Default Values

Bitcoin Core defines the default minimum relay fee in src/policy/policy.h:

// Bitcoin Core default (post-August 2025, PR #33106)
static constexpr unsigned int DEFAULT_MIN_RELAY_TX_FEE{100};
// 100 sat/kvB = 0.1 sat/vB

// Previous default (held for ~10 years)
// static constexpr unsigned int DEFAULT_MIN_RELAY_TX_FEE{1000};
// 1000 sat/kvB = 1 sat/vB

Node operators can override this default in their bitcoin.conf file. The value is specified in BTC per kilobyte:

# bitcoin.conf
# Set minimum relay fee to 0.1 sat/vB (the new default)
minrelaytxfee=0.000001

# Or set a custom higher threshold
minrelaytxfee=0.00005

The Rejection Process

When a transaction falls below the minimum relay fee, the node rejects it with RPC error code -26 and a message indicating the shortfall:

"min relay fee not met, 0 < 134"
// Transaction paid 0 sats, but 134 sats were required
// for its size at the current minrelaytxfee rate

The transaction is neither stored in the mempool nor forwarded to any peer. From the network's perspective, the transaction effectively does not exist until the sender rebroadcasts it with a higher fee.

Related Fee Policies

The minimum relay fee works alongside several other fee-related policies in Bitcoin Core. Understanding their interaction is important for developers building on Bitcoin:

These parameters were separated in Bitcoin Core PR #9380 so they could be tuned independently. The dustrelayfee was deliberately left unchanged at 3000 sat/kvB when the other two were lowered, preserving existing dust thresholds.

Dynamic Mempool Minimum

During periods of high congestion, the effective minimum fee can rise well above the static minrelaytxfee. When the mempool fills to its configured maximum size (default 300 MB), the node begins evicting the lowest-fee transactions. The eviction threshold becomes the new dynamic minimum: the fee rate of the last evicted transaction plus the incrementalrelayfee.

The effective minimum at any given moment is whichever is higher: the static minrelaytxfee or the dynamic mempool minimum. As congestion subsides and transactions confirm, the dynamic minimum decays back toward the static floor. This is why fee estimation tools report different minimum fees depending on current network conditions.

Why It Matters for Layer 2 Protocols

The minimum relay fee has significant implications for protocols that rely on pre-signed transactions, including the Lightning Network and other Layer 2 systems. These protocols create transactions at channel-open time with a fee rate that seemed reasonable then, but may fall below the minimum relay fee weeks or months later when the transaction actually needs to be broadcast.

Consider a Lightning commitment transaction signed with a fee rate of 0.5 sat/vB. Under the old 1 sat/vB minimum relay fee, this transaction would be rejected by every node on the network: it could never reach miners, making it impossible to force-close the channel. This is a safety-critical failure mode.

Several innovations have emerged to address this problem:

• Anchor outputs add small spendable outputs to commitment transactions, allowing either party to attach a CPFP child transaction that bumps the effective fee rate of the package above the relay threshold
• Package relay (1p1c) allows a parent transaction below minrelaytxfee to be relayed when bundled with a fee-paying child, so the package as a whole meets the threshold
• Ephemeral anchors use a special Pay-to-Anchor (P2A) output type that enables zero-fee parent transactions to be relayed as part of a package, fully decoupling the pre-signed fee rate from relay requirements

The August 2025 reduction to 0.1 sat/vB further eased this pressure, but the fundamental challenge remains for any protocol that pre-signs transactions: the relay fee floor may shift between signing and broadcast. For a deeper look at how fee bumping strategies work in practice, see the Bitcoin fee bumping guide and the v3 transactions and package relay analysis.

The Dust Limit Connection

The dust limit determines the smallest output value a node will relay. Historically, the dust threshold was calculated directly from the minimum relay fee: if the cost of spending an output (in fees) exceeds the output's value, that output is considered dust and rejected.

Today, Bitcoin Core uses a separate dustrelayfee parameter (defaulting to 3000 sat/kvB) for this calculation. The formula considers both the output's serialized size and the estimated size of the input needed to spend it:

Dust threshold = dustrelayfee × (output_size + spending_input_size)

P2PKH:  3 sat/vB × (34 + 148) = 546 satoshis
P2WPKH: 3 sat/vB × (31 + 67)  = 294 satoshis

When the minimum relay fee was lowered in August 2025, the dust limit was intentionally preserved by keeping dustrelayfee at its original value. This separation ensures that lowering the relay threshold for DoS protection does not inadvertently flood the UTXO set with economically unspendable outputs.

Use Cases

Spam Prevention

The primary use case is straightforward: preventing network abuse. Every unconfirmed transaction consumes resources across thousands of nodes: bandwidth for relay, CPU for validation, and memory for mempool storage. The minimum relay fee ensures that using these shared resources has a non-trivial cost, making large-scale spam attacks expensive.

Node Operator Configuration

Node operators running routing infrastructure or mining operations may adjust their minimum relay fee based on their specific needs. A mining pool that wants to capture the maximum range of fee-paying transactions might lower its threshold. A resource-constrained node might raise it to reduce mempool churn. This per-node flexibility is possible precisely because the relay fee is a policy, not consensus.

Fee Market Floor

The minimum relay fee establishes the floor of the fee market. During periods of low demand, when blocks have ample space, the relay fee becomes the effective minimum cost of a Bitcoin transaction. Understanding this floor is essential for applications that batch transactions or schedule consolidations during low-fee periods. For more on how the fee market operates, see the fee market dynamics deep dive.

The 2025 Reduction Debate

For approximately ten years, the minimum relay fee remained at 1 sat/vB (1000 sat/kvB). During that time, Bitcoin's USD exchange rate increased by two to three orders of magnitude, making the DoS protection cost far higher in real terms than originally intended.

In 2025, two competing proposals emerged to address this. The first (PR #32959 by RobinLinus, the author of BitVM) was closed in favor of a more comprehensive change (PR #33106 by Gloria Zhao), which lowered both minrelaytxfee and incrementalrelayfee from 1000 to 100 sat/kvB. The change was merged into Bitcoin Core master in August 2025 and backported to the v29.1 release.

The decision was not without controversy. Supporters argued that the 10x reduction restored the original economic intent of the parameter and that over 80% of miners were already accepting sub-1 sat/vB transactions. Critics argued that lowering the threshold weakened spam protection and that policy changes should not be backported to minor releases. The debate reflected a broader tension in Bitcoin governance: balancing network protection with the practical needs of users and Layer 2 protocols.

Risks and Considerations

Policy vs. Consensus Confusion

A common misconception is that the minimum relay fee is enforced by consensus. It is not. Any valid transaction can appear in a block regardless of its fee rate. The relay fee only determines whether nodes will propagate the transaction through the peer-to-peer network. A miner who receives a low-fee transaction directly (outside the relay network) can include it in a block without violating any consensus rules.

Network Fragmentation

Because each node sets its own relay fee independently, nodes with different settings may relay different sets of transactions. If a significant portion of the network raises their minimum relay fee, transactions paying just above the default may fail to propagate widely, reducing their chance of reaching miners. This creates a potential fragmentation risk where the effective relay fee depends on network topology rather than a single global constant.

Pre-Signed Transaction Risk

Any protocol that pre-signs transactions faces the risk that the minimum relay fee (or the dynamic mempool minimum) may rise above the pre-signed fee rate. While anchor outputs and package relay mitigate this for Lightning, other protocols using pre-signed transactions (such as vaults, inheritance schemes, or DLCs) must account for this scenario in their designs.

Spam Threshold Tradeoffs

Lowering the minimum relay fee makes the network more accessible for legitimate low-value transactions and Layer 2 anchor spends, but it also lowers the cost of spam attacks. At 0.1 sat/vB, filling a 300 MB mempool costs roughly 10x less than at 1 sat/vB. The ongoing debate about where to set this threshold reflects a fundamental tradeoff between openness and protection that has no universally correct answer.

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.