Routing Fees

What Are Routing Fees?

Routing fees are the small charges that Lightning Network nodes collect when they forward a payment on behalf of a sender. Every Lightning payment that crosses more than one hop passes through intermediate nodes, and each of those nodes deducts a fee before forwarding the remaining amount to the next hop. The cumulative fees across all hops determine the total routing cost for the sender.

Think of routing fees like tolls on a highway system. Each stretch of road (channel) has its own toll booth (node) that charges a fee for passing through. The sender pays all tolls upfront, and each node along the route takes its cut as the payment moves forward. Unlike highway tolls set by a central authority, Lightning routing fees are set by individual node operators in a free market.

Routing fees exist because operating a Lightning node has real costs: on-chain transaction fees for opening and closing channels, the opportunity cost of capital locked in channels, server infrastructure, and the effort of managing liquidity. Fees provide the economic incentive that keeps the network functional. For a deeper look at how liquidity shapes the network, see the Lightning Network liquidity explainer.

How It Works

Every Lightning channel has a fee policy advertised to the network through the gossip protocol. When a node opens or updates a channel, it broadcasts a channel_update message containing its fee parameters. Other nodes store these parameters and use them when computing routes for payments.

The Two Fee Components

Lightning routing fees consist of two independent components that are added together for each hop:

• Base fee: a fixed amount charged per forwarded HTLC, regardless of payment size. This covers the per-transaction overhead of processing and forwarding the payment. It is denominated in millisatoshis (msat), where 1 satoshi equals 1,000 msat.
• Fee rate (proportional fee): a variable amount proportional to the payment size, expressed in parts per million (ppm). A fee rate of 100 ppm means the node charges 100 satoshis for every 1,000,000 satoshis forwarded.

The total fee for a single hop is calculated as:

fee = base_fee + (amount * fee_rate / 1,000,000)

Example:
  base_fee  = 1,000 msat (1 sat)
  fee_rate  = 200 ppm
  amount    = 500,000 sats

  fee = 1,000 msat + (500,000 * 200 / 1,000,000) sats
  fee = 1 sat + 100 sats
  fee = 101 sats

For a multi-hop payment, the sender calculates the cumulative fee across all intermediate nodes before constructing the onion-routed payment. The sender includes enough extra satoshis in the first hop to cover all downstream fees.

Fee Advertisement via Gossip

Nodes announce their fee policies using channel_update messages defined in the BOLT specifications (specifically BOLT #7). Each channel has two channel_update messages: one from each side, because each node sets its own fee for forwarding in its direction.

The key fields in a fee announcement are:

channel_update {
  short_channel_id:    # identifies the channel
  fee_base_msat:       # base fee in millisatoshis
  fee_proportional_millionths:  # fee rate in ppm
  cltv_expiry_delta:   # timelock delta for this hop
  htlc_minimum_msat:   # minimum HTLC this node will forward
  htlc_maximum_msat:   # maximum HTLC this node will forward
}

Nodes throughout the network store these updates and use them to build a routing graph. When a sender wants to make a payment, their node runs a pathfinding algorithm (typically a variant of Dijkstra's algorithm) that factors in fees, channel capacity, and reliability to find the cheapest viable route. Technologies like multi-path payments allow splitting a single payment across multiple routes to optimize for cost and success probability.

How Senders Pay Fees

The sender pays all routing fees, not the receiver. When constructing a payment, the sender works backward from the destination:

1. Start with the payment amount the receiver should get
2. Add the fee for the last hop
3. Add the fee for the second-to-last hop (calculated on the running total)
4. Continue until reaching the first hop

Each intermediate node receives an HTLC for a slightly larger amount than it forwards. The difference is the node's fee. This mechanism is encoded inside the onion layers, so each node only knows its own fee and the next hop: it cannot see the total route fees or other nodes' earnings.

Fee Economics

Covering Channel Costs

Operating Lightning channels incurs several costs that fees need to offset:

• On-chain fees: opening and closing channels requires on-chain Bitcoin transactions, each with its own mining fee. During high-fee periods, a single channel open can cost tens of thousands of satoshis. Anchor outputs help manage fee uncertainty but add their own overhead.
• Capital lockup: every satoshi in a channel is a satoshi that cannot be invested, spent, or deployed elsewhere. The opportunity cost depends on market conditions and the operator's alternatives.
• Infrastructure: running a reliable node requires servers, monitoring, backup systems, and ongoing maintenance.
• Rebalancing: as payments flow through a node, channels become unbalanced. Circular rebalancing, Loop, and splicing all have costs that must be recouped.

Capital Opportunity Cost

The most significant cost for large routing nodes is the opportunity cost of locked capital. A node operator who commits 1 BTC to Lightning channels forgoes any returns that BTC could earn elsewhere. Routing fees must at least match the risk-adjusted return the capital could generate in alternative deployments.

This creates a natural floor for routing fees: if fees fall below the opportunity cost of capital, rational operators withdraw liquidity from Lightning. As liquidity decreases, remaining channels become more congested, fees rise, and an equilibrium emerges. In practice, many node operators also value the public good of supporting the network, which pushes fees below the pure economic optimum.

Fee Competition and the Race to Zero

Lightning routing is intensely competitive. Any node can undercut another by lowering fees, attracting more payment volume. This competition has driven median routing fees to very low levels: often under 1 satoshi per payment for well-connected nodes.

The "race to zero" concern asks whether fees can sustain a healthy routing network long-term. If fees become too low:

• Node operators cannot cover their costs and shut down channels
• Network capacity shrinks, reducing payment reliability
• Centralization pressure increases as only large, well-capitalized operators can afford to route at minimal margins

Counterarguments suggest that the market will find equilibrium. Nodes with superior connectivity, reliability, and inbound liquidity can charge premium fees because they offer higher payment success rates. Differentiation through service quality, not just price, may prevent a true race to zero.

Use Cases

Dynamic Fee Management

Sophisticated node operators use dynamic fee strategies rather than static fee settings. Common approaches include:

• Raising fees on channels with depleting local balance to discourage outbound flow and preserve liquidity
• Lowering fees on channels with excess local balance to attract outbound flow and rebalance naturally
• Setting asymmetric fees for inbound vs. outbound directions to shape traffic flow
• Time-based adjustments to capture higher fees during peak usage periods

Tools like Autoloop and third-party fee management software automate these strategies, continuously adjusting fees based on channel balance ratios and market conditions.

Liquidity Signaling

Fees serve as a signaling mechanism for channel liquidity. A node that raises fees on a particular channel is implicitly communicating that its liquidity on that side is running low. Other nodes can use this information for smarter pathfinding: high fees suggest a channel may fail, while low fees suggest ample capacity.

This signaling function means that fees carry information beyond their monetary value. They form a distributed price system that helps the network allocate liquidity efficiently without any central coordinator.

Revenue Generation

For professional routing node operators, fees represent the primary revenue stream. Large nodes processing thousands of payments daily can generate meaningful returns on their deployed capital. The annual yield depends on factors like node connectivity, capital deployment, fee strategy, and overall network payment volume.

Inbound Fee Proposals

Traditional Lightning fees only apply in the outbound direction: a node charges for payments leaving through its channels. However, there is growing interest in inbound fees, which would allow nodes to charge (or offer discounts) for payments arriving through a specific channel.

The asymmetry exists because current gossip messages only advertise outbound fee parameters. A node cannot signal, for example, "I want to discourage inbound flow on this channel because it already has too much inbound capacity." The only tool available is to raise outbound fees on the same channel, which is an imprecise and often counterproductive response.

Inbound fee proposals would add negative or positive fee fields to channel_update messages. A negative inbound fee acts as a discount: the node effectively pays senders to route payments through a channel it wants to rebalance. A positive inbound fee adds a charge for arriving payments, discouraging flow in that direction.

These proposals remain under discussion in the Lightning development community. If adopted, they would give node operators much finer control over liquidity management and could reduce the need for expensive circular rebalancing operations.

Risks and Considerations

Fee Estimation and Overpayment

Senders must estimate total route fees before sending a payment. Because channel states change rapidly, the fee information in a sender's routing graph may be stale. This can lead to failed payments (if a node has raised fees) or overpayment (if fees have dropped since the last gossip update).

Trampoline routing addresses this partially by delegating pathfinding to well-connected nodes that maintain fresher routing data, though this introduces some privacy tradeoffs.

Probing and Privacy

Fee policies are public information broadcast through gossip, but actual channel balances are private. Attackers can use probing techniques to infer channel balances by sending payments that are designed to fail. Combined with fee data, probing can reveal how much liquidity a channel has on each side, undermining privacy.

Blinded paths and route hints offer partial mitigations by hiding portions of the route from the sender.

Centralization Pressure

If routing fees remain very low, only large operators with economies of scale can profitably run routing nodes. This could lead to a hub-and-spoke topology where a few dominant nodes handle most traffic, undermining the decentralization goals of the Lightning Network.

Solutions being explored include protocol-level improvements like channel factories (which reduce on-chain costs per channel) and PTLCs (which reduce the overhead per forwarded payment), both of which lower the cost floor for operating a routing node.

Fee Sniping and Manipulation

Because fee updates propagate asynchronously through gossip, there is a window where different parts of the network see different fee rates for the same channel. Sophisticated actors could exploit these inconsistencies by rapidly changing fees to capture routing traffic or manipulate payment paths. While not a widespread issue today, it becomes more relevant as payment volumes grow and routing becomes more competitive.

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.