Channel Update (Lightning Gossip)

What Is a Channel Update?

A channel_update is a signed message in the Lightning Network's gossip protocol that communicates the routing policy for one direction of a payment channel. Defined in BOLT 7, it tells other nodes on the network how much a channel partner charges to forward payments, what timelock margin it requires, and the minimum and maximum HTLC sizes it will accept.

Every public channel has two directions: one from node A to node B, and another from node B to node A. Each node independently broadcasts its own channel_update for the direction it controls. This means a single channel produces at least two channel_update messages, and nodes across the network store both to build a complete picture of the routing graph.

Without channel_update messages, remote nodes would have no way to calculate valid payment routes. The Lightning routing system depends entirely on the fee and policy data these updates provide.

How It Works

When a node opens a public channel or changes its forwarding policy, it constructs a channel_update message, signs it with its node key, and floods it to peers. Each peer validates the signature, checks whether the update is newer than what it already has (using the timestamp field), and relays it onward if valid.

Message Fields

The channel_update message (type 258) contains the following fields, each carrying specific routing information:

channel_update (type 258)
├── signature          (64 bytes)  // Signs all fields below
├── chain_hash         (32 bytes)  // Identifies the blockchain (mainnet, testnet)
├── short_channel_id   (8 bytes)   // Block height + tx index + output index
├── timestamp          (4 bytes)   // Unix time; newer replaces older
├── message_flags      (1 byte)    // Bit 0: htlc_maximum_msat present (now mandatory)
├── channel_flags      (1 byte)    // Bit 0: direction, Bit 1: disable
├── cltv_expiry_delta  (2 bytes)   // Minimum timelock delta for forwarding
├── htlc_minimum_msat  (8 bytes)   // Smallest HTLC accepted
├── fee_base_msat      (4 bytes)   // Flat fee per forwarded HTLC
├── fee_proportional_millionths (4 bytes)  // Fee rate in parts per million
└── htlc_maximum_msat  (8 bytes)   // Largest HTLC accepted

Key Fields Explained

The channel_flags bitfield serves two purposes. Bit 0 indicates the direction of the update: whether it applies to node 1 forwarding toward node 2, or vice versa. Bit 1 is the disable flag, which signals that the channel is temporarily unavailable for routing. Nodes set this flag when a peer goes offline or when they want to stop routing through that channel.

The fee fields define the cost of forwarding an HTLC through this channel direction. The total routing fee is calculated as:

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

For example, a channel with a base fee of 1,000 msat (1 sat) and a proportional rate of 100 (0.01%) would charge 1,100 msat to forward a 100,000 msat payment: 1,000 + (100,000 * 100 / 1,000,000) = 1,100 msat.

The cltv_expiry_delta specifies the minimum difference in block height between an incoming and outgoing HTLC's timelock. If a forwarding node receives an incoming HTLC with a CLTV expiry of 800,000 and its delta is 40, the outgoing HTLC's expiry must be no later than block 799,960. This margin protects the forwarding node by ensuring it has time to claim funds on-chain if necessary. Common defaults range from 34 blocks (Core Lightning) to 80 blocks (LND) to 144 blocks (Eclair).

Timestamps and Replacement

Each channel_update includes a Unix timestamp. When a node receives a new update for the same channel direction, it keeps the one with the higher timestamp and discards the older one. This ensures the network converges on the most recent policy.

Channels whose most recent update is older than approximately two weeks are pruned from the routing graph. This means nodes must periodically rebroadcast their channel_update even if nothing has changed, just to keep the channel visible. These keep-alive updates, which carry identical policy data with only a refreshed timestamp, account for a significant portion of all gossip traffic.

Why It Matters

Channel_update messages are the foundation of Lightning payment routing. Every time a wallet constructs a payment path, it reads the fee and CLTV data from channel_update messages stored in its local routing graph. Without accurate, up-to-date channel updates, payments fail because senders calculate incorrect fees or timelocks.

For routing node operators, channel_update messages are the primary tool for managing their business: adjusting fees to attract or discourage traffic, setting HTLC limits to manage channel capacity, and disabling channels that need maintenance.

Layer 2 solutions like Spark take a different approach by avoiding the channel-based architecture entirely. Because Spark uses statechains (vUTXOs) instead of payment channels, there is no need for channel_update gossip, eliminating a significant source of bandwidth overhead and routing complexity.

Use Cases

Fee-Based Routing Optimization

Routing nodes use channel_update messages to implement dynamic fee strategies. A node with imbalanced channels can raise fees on the depleted side and lower fees on the full side, encouraging traffic that rebalances liquidity naturally. The forwarding policy expressed in each update directly shapes which payments the network routes through that channel.

Channel Availability Signaling

When a channel peer goes offline or a node needs to perform maintenance, it broadcasts a channel_update with the disable bit set in channel_flags. This tells the network to stop routing through that channel. When the channel is ready again, a new update with the disable bit cleared restores it to the routing graph.

Pathfinding Input

Pathfinding algorithms consume channel_update data to calculate the cheapest or fastest route for a payment. The fee fields determine cost, the HTLC min/max fields determine whether the payment amount fits, and the CLTV delta determines the total timelock budget needed for the route. Wallets weigh these factors to choose optimal paths through multi-hop routes.

Network Graph Construction

Every Lightning node maintains a local copy of the network graph built from gossip messages. The channel_announcement message establishes that a channel exists, while channel_update messages fill in the routing parameters. Together, these two message types let any node on the network compute routes to any other node without relying on a central directory.

Risks and Considerations

Gossip Spam and Bandwidth

Channel_update messages are flooded across the entire network. Every node that receives a valid update relays it to all its peers. On a network with thousands of channels, this creates substantial bandwidth consumption. Research has found that keep-alive updates (identical content, refreshed timestamp) account for roughly 45% of all channel_update traffic, adding overhead without conveying new routing information.

To manage this, implementations enforce rate limits. Core Lightning allows approximately one channel_update per channel per day on average, with a burst allowance of up to four. Other implementations take different approaches: some enforce strict limits while others rely on nodes to self-regulate.

Mobile Client Overhead

Mobile Lightning wallets face a particular challenge with channel_update gossip. Syncing the full routing graph requires downloading and processing thousands of updates, which consumes battery and bandwidth. Solutions like Rapid Gossip Sync compress the gossip data into a compact snapshot that mobile clients can download from a server, trading some trust assumptions for dramatically reduced sync times. For a deeper analysis of this tradeoff, see the research on Lightning gossip bandwidth and mobile scaling.

Stale Data and Payment Failures

If a sender's local graph contains outdated channel_update data, it may construct routes with incorrect fees or timelocks. The forwarding node will reject the HTLC because it doesn't match the current policy, causing the payment to fail. The sender must then re-route, adding latency. Frequent channel closures and policy changes exacerbate this problem.

Channel Flapping

Nodes with unreliable connections, particularly those running over Tor, can cause rapid alternation between enabled and disabled states. Each toggle produces a new channel_update, creating a burst of gossip messages known as "flapping." Studies have found that roughly 18% of public half-channels trigger rate-limiting rules at least once over a two-week period, largely due to intermittent connectivity. This degrades routing reliability because other nodes cannot determine whether the channel is actually available.

Privacy Implications

Channel_update messages are public: anyone monitoring the gossip network can see fee changes and channel availability in real time. This reveals information about a node's operational behavior, including when it goes offline, when it adjusts fees (potentially signaling liquidity depletion), and which channels it prioritizes. Private channels avoid this by not broadcasting gossip messages at all, though they sacrifice discoverability.

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.