Forwarding Policy (Lightning)

What Is a Forwarding Policy?

A forwarding policy is the configuration a Lightning Network node uses to decide whether to relay an incoming HTLC through one of its channels. Each channel has two independent policies: one for each direction, set unilaterally by the node on that side. When a node receives a payment it did not originate and is not the final recipient of, it checks the forwarding policy for the outgoing channel to determine whether to accept or reject the routing request.

Think of it as a toll booth on a highway. Each node sets its own prices and vehicle restrictions for traffic passing through. Senders learn these rules in advance through the gossip protocol and use them to calculate the cheapest or fastest route for their payment.

How It Works

A forwarding policy consists of five core parameters. Together, they define the cost and constraints for routing a payment through a specific channel direction.

Policy Components

Fee Calculation

The total routing fee for a single hop is calculated using the formula defined in BOLT #7:

fee >= fee_base_msat + (amount_to_forward * fee_proportional_millionths / 1,000,000)

For example, forwarding 1,000,000 sats through a channel with a base fee of 1,000 msat and a fee rate of 500 ppm yields:

fee = 1,000 + (1,000,000 × 500 / 1,000,000)
    = 1,000 + 500
    = 1,500 msat (1.5 sats)

The sender calculates the cumulative fee across every hop in the route before initiating payment. Each intermediate node verifies that the incoming HTLC amount covers its fee plus the outgoing amount.

The CLTV Expiry Delta

The CLTV expiry delta determines how much time buffer a forwarding node requires between the incoming and outgoing HTLCs. If the outgoing HTLC fails to resolve, the node needs enough blocks to claim the incoming HTLC on-chain before its own timelock expires. Larger deltas provide more safety but increase the total route timelock, which ties up funds longer and makes channels less attractive to senders.

Announcing Policies via Gossip

Forwarding policies are communicated to the network through gossip protocol messages defined in BOLT #7. The process follows three steps:

1. Both channel peers sign a channel_announcement message proving the channel exists on-chain and identifying both nodes
2. Each node independently broadcasts a channel_update message containing its forwarding policy for its direction of the channel
3. Receiving nodes validate the signatures and relay the update to their peers, propagating it across the network within roughly 30 seconds per hop

Nodes can update their forwarding policy at any time by broadcasting a new channel_update with a higher timestamp. The newer message supersedes the old one across the network. Gossip messages are only relayed for nodes with at least one public channel, which prevents spam since opening a channel requires locking bitcoin on-chain.

Default Values by Implementation

The three major Lightning implementations ship with different default forwarding policies. Node operators typically adjust these based on their routing strategy:

The wide variation in defaults: LND at 1 ppm vs. Eclair at 200 ppm for fee rate, for instance: reflects different philosophies about whether new nodes should prioritize attracting routing volume or covering costs from the start.

Fee Strategy Considerations

Setting forwarding policies is one of the central challenges of running a routing node. Operators balance three competing goals:

• Attracting routing volume by keeping fees competitive with alternative paths through the network
• Covering the on-chain costs of opening and closing channels, which sets a minimum profitability threshold
• Managing channel balance by adjusting fees dynamically: lower fees when local balance is high (encouraging outflow) and higher fees when the channel is being drained

Common Strategies

Many operators are moving toward zero base fees. A zero base fee benefits multipath payments because the flat per-HTLC charge penalizes splitting a payment across multiple routes. With proportional-only pricing, senders can split payments freely without incurring extra fixed costs per path.

Dynamic Fee Management

Sophisticated routing nodes adjust fees automatically based on channel state. Tools like charge-lnd implement balance-proportional fee policies: when a channel's local balance drops below a threshold, fees increase to discourage further outflow. When local balance is high, fees decrease to attract routing volume in that direction.

This creates a natural market mechanism where fees reflect real-time liquidity availability rather than static configuration. For a deeper look at how routing economics work, see the Lightning routing deep dive.

Private Channels and Route Hints

Private (unannounced) channels are not broadcast via the gossip protocol, so their forwarding policies are invisible to the network. These channels cannot serve as intermediate hops for arbitrary third-party routing since no one knows they exist.

To receive payments through a private channel, the recipient includes route hints in their BOLT #11 invoice. Each route hint contains the forwarding policy parameters: fee_base_msat, fee_proportional_millionths, and cltv_expiry_delta: along with the node's public key and the short channel ID. This gives the sender enough information to construct a complete route to the recipient.

The trade-off is privacy. Route hints reveal the recipient's channel partners and some liquidity information, which partially undermines the privacy benefits of keeping a channel unannounced.

How Spark Eliminates Forwarding Policies

Forwarding policies exist because the Lightning Network relies on multi-hop routing: payments travel through a chain of intermediate nodes, each of which must be compensated for locking liquidity and bearing counterparty risk. Every hop adds fees, latency, and potential failure points.

Spark takes a fundamentally different approach. As a Layer 2 protocol built on statechains, Spark transfers ownership of virtual UTXOs directly between parties without routing through intermediaries. There are no forwarding nodes, no channel balancing, and no fee markets to navigate. This eliminates an entire category of complexity that Lightning node operators must manage.

Risks and Considerations

Stale Gossip Data

Forwarding policies propagate through the network with some delay. A sender might calculate a route using outdated fee data, only to have the payment rejected because the forwarding node updated its policy after the sender's last gossip sync. Implementations mitigate this through Rapid Gossip Sync and by retrying with updated channel data after failures.

Race to the Bottom

Competitive fee pressure can push routing fees below the level needed to cover on-chain channel management costs. Node operators who set fees too low attract volume but may lose money when accounting for channel opens, closes, and rebalancing costs. Profitable routing typically requires significant capital deployment (5+ BTC in channel capacity) and active management.

Channel Jamming via Policy Abuse

Attackers can exploit forwarding policies by sending payments designed to lock up channel liquidity. A channel jamming attack floods a node with HTLCs that consume its available slots or capacity, preventing legitimate payments from being forwarded. Policy settings like htlc_minimum_msat and maximum in-flight HTLC counts provide some defense, but the problem remains an active area of research in the Lightning protocol community.

Privacy Leakage

Forwarding policies are public by design. Combined with payment probes, an observer can infer channel balances by testing which payment amounts a channel will forward. Unique fee configurations can also serve as fingerprints that help identify specific nodes in the routing path, weakening the privacy guarantees of onion routing.

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.