Base Fee (Lightning)

What Is a Base Fee?

A base fee (formally fee_base_msat in the BOLT specification) is one of two fee parameters that a Lightning Network routing node advertises to the network. It is a fixed charge, denominated in millisatoshis, that the node applies to every HTLC it forwards. Unlike the proportional fee rate, the base fee does not scale with payment size: a node charging a 1,000 msat base fee charges the same flat amount whether it routes 100 sats or 1,000,000 sats.

Think of it like a flat processing fee. Just as a wire transfer might carry a fixed fee regardless of the amount sent, the base fee compensates routing nodes for the per-transaction overhead of forwarding a payment: CPU cycles, bandwidth, commitment transaction updates, and revocation state storage. The proportional fee rate then adds a variable charge that scales with the amount, covering the opportunity cost of tying up channel liquidity.

Together, these two parameters form a two-part pricing model defined in BOLT #7, and every routing node broadcasts them via gossip protocol channel_update messages so that senders can calculate costs before constructing a route.

How It Works

When a sender constructs a payment route through the Lightning Network, the pathfinding algorithm evaluates each candidate hop's fee parameters to estimate total cost. At each intermediate node, the fee is calculated using this formula:

fee = base_fee_msat + (amount_msat × fee_rate_ppm / 1,000,000)

Where base_fee_msat is the flat charge in millisatoshis, amount_msat is the forwarded amount in millisatoshis, and fee_rate_ppm is the proportional rate in parts per million. The total routing fee for a multi-hop payment is the sum of fees at each intermediate node. The sender's own node and the final recipient do not charge routing fees.

Worked Example

Consider routing 100,000 sats through a three-hop path where each node has different fee parameters:

Hop 1: base_fee = 1,000 msat, fee_rate = 100 ppm
  fee = 1,000 + (100,000,000 × 100 / 1,000,000) = 1,000 + 10,000 = 11,000 msat (11 sats)

Hop 2: base_fee = 0 msat, fee_rate = 200 ppm
  fee = 0 + (100,000,000 × 200 / 1,000,000) = 0 + 20,000 = 20,000 msat (20 sats)

Hop 3: base_fee = 500 msat, fee_rate = 50 ppm
  fee = 500 + (100,000,000 × 50 / 1,000,000) = 500 + 5,000 = 5,500 msat (5.5 sats)

Total routing fee: 11 + 20 + 5.5 = 36.5 sats

Notice that Hop 2 uses a zero base fee. Its entire fee scales linearly with the payment amount, which simplifies cost prediction for senders and treats small payments more equitably.

Default Values by Implementation

Each major Lightning implementation ships with different default base fee values:

CLN's near-zero default reflects its alignment with the zero-base-fee philosophy. Its renepay pathfinding plugin is built on the Pickhardt-Richter minimum-cost-flow framework, which performs best when base fees are eliminated. Node operators can adjust these defaults through configuration to match their routing strategy.

The Zero-Base-Fee Debate

One of the most significant routing policy debates in the Lightning community centers on whether base fees should be set to zero. The discussion has practical implications for micropayment economics, pathfinding efficiency, and multi-path payment optimization.

Arguments for Zero Base Fees

Researchers Rene Pickhardt and Stefan Richter demonstrated in their 2021 paper that finding the cheapest multi-part payment route is NP-hard when base fees are present. Base fees introduce a nonlinear cost component because the fixed charge applies per split, meaning the total cost depends on how the payment is divided across paths. Removing base fees converts the problem into a linear minimum-cost flow problem solvable in polynomial time.

Additional arguments for zero base fees include:

• Micropayment fairness: a 1-sat base fee represents 10% of a 10-sat payment but only 0.001% of a 100,000-sat payment, creating a regressive fee structure
• Simpler fee prediction for wallets and senders, since costs scale linearly with the payment amount
• Better MPP splitting decisions, as pathfinding algorithms can optimize splits without accounting for per-hop fixed costs

Arguments Against Zero Base Fees

Proponents of maintaining base fees point to the real fixed costs of forwarding each HTLC:

• Processing overhead: each forwarded HTLC requires CPU cycles, bandwidth, and commitment transaction updates regardless of payment size
• Spam protection: without a minimum per-payment cost, nodes are more vulnerable to being flooded with tiny payments that consume resources without generating meaningful revenue
• Revocation state storage: nodes must store revocation keys for each channel state update, and watchtowers must track this data until channel closure
• Revenue floor for small operators who route modest volumes and need a minimum income per forwarded payment to cover infrastructure costs

Impact on Micropayments

Base fees have the most dramatic effect on small-value payments. The table below illustrates how a common 1-sat base fee impacts payments of different sizes (assuming a single hop with 200 ppm fee rate):

For a three-hop route with 1-sat base fees at each node, a 10-sat micropayment would incur 3 sats in base fees alone: a 30% overhead before proportional fees are even counted. This is why zero-base-fee routing is considered essential for use cases like payment streaming, per-second billing, and other micropayment patterns. For a deeper look at how Lightning enables small-value payments, see the micropayments use cases research article.

Comparison with On-Chain Fees

Lightning routing fees and on-chain Bitcoin transaction fees operate on fundamentally different models. On-chain fees are determined by transaction size in virtual bytes and mempool congestion, not payment amount. A 100-sat on-chain transaction costs the same in fees as a 1,000,000-sat transaction of the same byte size.

Lightning routing fees, by contrast, scale with the payment amount (through the proportional component) and the number of hops (through accumulated base fees). In practice, Lightning fees are typically 100x to 10,000x cheaper than on-chain fees: routing 100,000 sats might cost 20 to 50 sats on Lightning, compared to 2,000 to 50,000+ sats on-chain during moderate congestion. This cost advantage is one of the primary motivations for using layer-2 payment networks. For further comparison, see the Lightning Network routing deep dive.

Why It Matters

Base fee policy affects the entire Lightning Network ecosystem. For node operators, the base fee is a lever for balancing revenue against routing attractiveness: lower base fees attract more payment volume, while higher base fees protect against resource abuse. For wallet developers, base fees complicate fee estimation and pathfinding algorithms. For end users, base fees determine whether sub-satoshi or very small payments are economically practical.

Protocols that build on Lightning, such as Spark, benefit from understanding base fee dynamics because they influence the cost structure of any payments that touch Lightning infrastructure. As the network matures and fee competition intensifies, the trend toward lower base fees is expected to continue, making Lightning increasingly viable for small and frequent payments.

Risks and Considerations

Fee Misconfiguration

Node operators who set base fees too high may be excluded from payment routes entirely, as pathfinding algorithms prefer cheaper paths. Operators who set fees too low may fail to cover their operational costs, especially during periods of high channel jamming or spam activity.

Fee Update Propagation

When a node changes its base fee, the updated parameters must propagate through the gossip network before senders use the new values. During this propagation window, senders may calculate routes using stale fee data, causing payments to be rejected by nodes expecting the updated fee. The BOLT spec recommends that nodes accept HTLCs paying older fee rates for a reasonable period after broadcasting an update.

Negative Fees

Core Lightning introduced experimental support for negative routing fees in 2026, where a node effectively pays senders to route through specific channels. This is primarily used for automated liquidity rebalancing and is cheaper than circular rebalancing or submarine swaps. Negative base fees add another dimension to fee policy that node operators must consider.

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.