Routing Node (Lightning Network)

What Is a Routing Node?

A routing node is a Lightning Network node that forwards payments on behalf of other participants in the network. While any Lightning node can send and receive payments for itself, a routing node takes on the additional role of relaying payments between peers, acting as an intermediary hop in multi-hop payment paths.

The Lightning Network is a payment channel network: not every user has a direct channel with every other user. When Alice wants to pay Carol but has no direct channel to her, a routing node that has channels with both Alice and Carol can forward the payment. In exchange, the routing node collects a small fee.

Routing nodes form the backbone of the Lightning Network. Without them, users would need direct channels with every counterparty, which is impractical. As of mid-2026, the Lightning Network has over 15,000 active public nodes and more than 50,000 public channels, with a public capacity exceeding 5,600 BTC.

How It Works

Payment forwarding on Lightning uses HTLCs (Hashed TimeLock Contracts) and onion routing. The sender constructs the full payment path and wraps routing instructions in layers of encryption, so each intermediary node knows only the previous and next hop.

1. The sender identifies a route through the network using pathfinding algorithms and the gossip protocol data
2. The sender creates an onion-encrypted packet containing instructions for each hop
3. Each routing node receives an incoming HTLC from its upstream peer, decrypts its layer, and creates a new outgoing HTLC to the next peer with a slightly lower amount (deducting its fee) and a shorter timelock
4. When the payment reaches the recipient, they reveal the preimage to claim funds
5. The preimage propagates back through each hop, allowing each routing node to settle its incoming HTLC and claim its fee

The HTLC mechanism ensures that routing nodes cannot steal funds: they can only claim the incoming payment by forwarding the outgoing payment and relaying the preimage. The decreasing timelocks at each hop (the CLTV delta) give each node time to claim their funds even if a downstream node delays.

Fee Structure

Routing nodes set two fee parameters per channel that determine the cost of forwarding a payment:

• Base fee (base_fee_msat): a flat fee in millisatoshis charged per forwarded HTLC, regardless of payment size. A common default is 1,000 msat (1 sat).
• Fee rate (fee_rate_ppm): a proportional fee in parts per million (ppm) of the forwarded amount. A rate of 100 ppm means 100 sats per 1,000,000 sats routed. Typical values range from 20 to 500 ppm depending on channel demand and liquidity.

The total fee for a forwarded payment is calculated as:

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

Recent Lightning implementations also support inbound fee discounts (negative inbound fees), allowing nodes to incentivize traffic in specific directions and assist with channel balance management. For a deeper look at how fee markets work, see the research article on Lightning Network routing.

Pathfinding and Route Selection

Senders select routes using modified Dijkstra's shortest-path algorithms, weighting channels by fee cost, estimated success probability, and timelock requirements. Modern implementations like LND track historical payment success/failure data per channel to improve routing decisions over time, prioritizing reliable paths over the cheapest ones.

When a payment fails along a route, the sender can retry with an alternative path. Multi-path payments (MPP) allow splitting a single payment across multiple routes simultaneously, increasing the chance of success for larger amounts.

Operational Requirements

Running a profitable routing node is operationally demanding. Key requirements include:

• Hardware: a dedicated machine with at least a quad-core CPU, 2+ GB RAM, and SSD storage. A full Bitcoin node (required for most Lightning implementations) needs over 800 GB of disk space and growing.
• Uptime: routing nodes must be online continuously. An offline node cannot forward payments and may trigger force-closures of channels if it remains unreachable for too long.
• Capital: meaningful routing requires significant Bitcoin locked in channels. Operators with fewer than 2-3 BTC of channel capacity typically struggle to route enough volume to cover costs.
• Channel management: operators must select well-connected peers, set competitive fees, and maintain balanced channels across both inbound and outbound liquidity.

Channel Rebalancing

As payments flow through a channel in one direction, the balance shifts: one side gains sats while the other loses them. Eventually, a channel becomes depleted in one direction and can no longer route payments that way. Routing nodes must regularly rebalance their channels to maintain bidirectional capacity.

Common rebalancing strategies include:

• Circular rebalancing: sending a payment from a channel with excess outbound liquidity through the network back to yourself via a channel needing outbound. The cost is the routing fees paid to intermediate nodes.
• Loop Out/In: using submarine swaps to move funds between on-chain Bitcoin and Lightning channels. Loop Out frees up inbound capacity; Loop In adds outbound capacity.
• Autoloop: automating Loop swaps based on configurable balance thresholds, reducing the need for manual intervention.
• Splicing: resizing channels on-the-fly by adding or removing funds without closing and reopening them.

Rebalancing is often the largest operating cost. One publicly documented case showed a node operator spending 542 ppm on rebalancing while earning only 140 ppm in routing fees, resulting in a net loss until the operator optimized channel selection and fee policies.

Economics of Running a Routing Node

Routing node economics are challenging for independent operators. Revenue comes from forwarding fees, but costs include channel opening/closing on-chain fees, rebalancing expenses, hardware, electricity, and the opportunity cost of locked capital.

• Large institutional operators with captive payment flows (such as exchanges routing their own user payments) have reported annualized returns of approximately 5-10% on deployed capital
• Independent mid-size operators with around 10 BTC deployed may route 1-2 BTC per day, earning roughly 30,000 sats daily, often near break-even after rebalancing costs
• Profitability depends heavily on channel selection, fee policy, and positioning within the network graph: nodes connected to high-volume endpoints earn disproportionately more

The economic reality is that routing remains a thin-margin business with competitive fee pressure. As more nodes enter the network, fee rates tend to compress, benefiting payment senders but squeezing router margins.

Routing Node vs. LSP

Most Lightning wallet users do not run their own routing nodes. Instead, they connect through an LSP (Lightning Service Provider) that handles channel management, liquidity provisioning, and payment routing on their behalf.

For most users and businesses building on Lightning, connecting through an LSP is the practical choice. Solutions like Spark take this further by moving payments off-chain entirely, eliminating the need for users to manage channels or rely on routing node infrastructure. For a comparison of approaches, see the research on Lightning Service Providers.

Major Implementations

Four primary Lightning implementations support routing node operation:

LND is the most widely deployed routing implementation. Here is an example of configuring routing fees on an LND node:

# Set channel fees via lncli
# Base fee: 1000 msat (1 sat), Fee rate: 200 ppm
lncli updatechanpolicy \
  --base_fee_msat 1000 \
  --fee_rate_ppm 200 \
  --chan_point <funding_txid>:<output_index>

# View current channel fees
lncli feereport

# List all forwarded payments
lncli fwdinghistory --start_time=-24h

Risks and Considerations

Channel Jamming

Channel jamming attacks exploit routing nodes by locking up channel capacity or HTLC slots with payments that are never completed. Amount jamming locks liquidity by sending large HTLCs that are held indefinitely, while slot jamming fills the limited number of HTLC slots (typically 483 per channel direction) with many small payments.

Proposed mitigations include upfront fees for holding HTLCs, reputation systems, and HTLC endorsement signaling. These solutions remain under active development in the Lightning protocol community.

Fee Competition

Setting routing fees is a balancing act. Fees set too high cause senders to route around the node. Fees set too low attract high volumes that rapidly deplete channel liquidity, requiring expensive rebalancing. Some operators use dynamic fee adjustment tools that raise fees on depleted channels and lower them on well-balanced ones.

Capital Inefficiency

Routing nodes must lock Bitcoin in channels that may sit idle for extended periods. Unlike staking or lending, locked channel funds earn nothing unless payments are actively routed through them. This opportunity cost is often the largest hidden expense of routing node operation.

Privacy Considerations

Routing nodes can observe the amount and timing of payments they forward, though onion routing prevents them from identifying the original sender or final recipient. Blinded paths and PTLCs are being developed to further reduce the information available to routing intermediaries.

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.