Channel Jamming

What Is Channel Jamming?

Channel jamming is a denial-of-service attack against the Lightning Network where an attacker renders payment channels unusable by filling them with payments that are never resolved. The attacker routes payments through victim channels and deliberately holds them open, consuming either the channel's liquidity or its available HTLC slots. Because failed payments on Lightning incur no routing fees, the attacker pays essentially nothing to execute the attack and receives a full refund when the payments eventually time out.

The attack is a form of routing attack that targets the economic incentive structure of payment forwarding. Routing nodes invest capital in Lightning channels to earn fees, but a jammer can neutralize that investment at negligible cost. This asymmetry between attack cost and defender cost is what makes channel jamming one of the most discussed open problems in Lightning Network security.

How It Works

Channel jamming comes in two variants, each targeting a different resource constraint in Lightning channels. Both exploit the same underlying mechanism: HTLCs that are sent but never settled.

Liquidity Jamming

In liquidity jamming (also called amount jamming), the attacker sends large payments through victim channels and refuses to finalize them. The attacker controls nodes on both ends of a route: one to send the payment and another to receive it without releasing the preimage. This locks the channel capacity in pending HTLCs until the timelock expires.

A single payment can traverse up to 20 hops on Lightning, meaning an attacker with a certain amount of capital can lock up roughly 20 times that amount across the network. Once the timelock expires and the payment fails, the attacker recovers their full balance and can repeat the attack immediately.

Slot Jamming

Slot jamming targets the HTLC slot limit rather than channel balance. Per the BOLT specification, each channel direction can hold a maximum of 483 concurrent in-flight HTLCs. This limit exists because a commitment transaction must remain small enough to be valid on-chain, and each pending HTLC adds an output to that transaction.

The attacker sends 483 minimum-value payments through a victim channel, filling every available slot. Even though each individual payment is tiny, no further payments can be routed through the channel until the existing HTLCs resolve. Slot jamming is generally cheaper than liquidity jamming because it requires only 483 × min_htlc_value in capital rather than the full channel balance.

Attack Economics

Research by Gleb Naumenko and Antoine Riard quantified the costs. Jamming a small routing node (fewer than six channels) costs approximately 156 sats to open the attacking channel plus roughly 200 sats per month in opportunity cost. Even a well-connected node with over 200 channels can be jammed for about 5,200 sats in opening costs and 6,700 sats per month. To degrade network-wide payment success by targeting approximately 20% of channels, the total cost ranges from 80,000 to 480,000 sats in opening fees.

# Simplified attack flow (slot jamming)

Attacker Node A ──── Victim Channel ──── Attacker Node B

1. A sends 483 min-value HTLCs through Victim to B
2. B receives HTLCs but never releases preimages
3. All 483 HTLC slots on Victim channel are consumed
4. Honest payments through Victim channel fail
5. After CLTV timeout: HTLCs expire, A gets full refund
6. Attack repeats at zero net cost

Why It Matters

Channel jamming threatens the viability of Lightning as a scalable payment network. Routing nodes are the backbone of the network: they provide liquidity, forward payments, and earn routing fees as compensation. If an attacker can cheaply deny these nodes their revenue, the economic incentive to run routing infrastructure weakens. For a deeper look at how routing economics work, see the Lightning routing deep dive.

The attack also has competitive implications. A rival routing node could jam competitors' channels to capture their routing market share. This creates a perverse incentive structure where the cheapest path to routing revenue is not improving service quality but sabotaging competitors.

For users, jammed channels mean failed payments, longer route-finding, and a degraded experience. For the broader ecosystem, an unsolved jamming problem limits how much capital rational operators are willing to commit to Lightning channels, which constrains inbound liquidity across the network. The scalability limits of Lightning are closely tied to whether these incentive problems can be resolved.

Impact on Routing Nodes

The consequences for targeted routing nodes are severe across several dimensions:

• Locked liquidity: jammed channels cannot route any payments until HTLC timelocks expire, which can take days to weeks depending on the CLTV delta configuration
• Lost fee revenue: while channels are jammed, the node earns zero routing fees on those channels with no compensation for the locked capital
• Reputation damage: the node appears unreliable to the network's pathfinding algorithms, causing senders to route around it even after the jam ends
• Cascading effects: jamming well-connected hub nodes degrades payment success rates across the broader network, as documented in research on Lightning liquidity dynamics

Proposed Solutions

The Lightning development community has proposed several mitigation strategies. No single approach has gained consensus, and each involves meaningful tradeoffs.

Upfront Fees

The most direct solution: charge a small fee for every HTLC forwarded, regardless of whether the payment succeeds. This breaks the core assumption that failed payments are free, making sustained jamming expensive. Research suggests that increasing total fees by just 2% (paid unconditionally) would fully compensate routing nodes under attack.

The tradeoff is that honest users also pay for failed payment attempts, which are a normal part of Lightning pathfinding. To mitigate this, a variant called "routing tokens" has been proposed where successful payments earn replacement tokens for future routing, so only persistent failures accumulate cost.

HTLC Endorsement

The current leading candidate for near-term deployment, formalized as BLIP-4. Nodes track per-peer profitability and assign local reputation scores. HTLCs from profitable peers are marked as "endorsed" and receive priority access to channel resources. Unendorsed HTLCs are served on a best-effort basis from a restricted resource pool.

The key property: to build enough reputation to fully occupy a channel's resources, an attacker must pay the target more in routing fees than it would have earned during normal operation. As of 2025, LND has added support for relaying experimental endorsement signals, and Eclair has implemented per-peer reputation tracking. LDK is building observational support that logs mitigation decisions without enforcing them yet.

Circuit Breakers

Software firewalls that sit in front of a routing node and apply per-peer limits on in-flight HTLCs. The CircuitBreaker tool (created by Joost Jager) implements rate limiting via token bucket algorithms with two modes: "fail" (rejects excess HTLCs immediately) and "queue" (buffers them). Currently available for LND nodes, circuit breakers provide immediate per-node protection without requiring network-wide protocol changes.

Stake Certificates

Proposed by Naumenko and Riard, stake certificates require senders to prove UTXO ownership when routing payments. This raises the Sybil cost for attackers because acquiring enough UTXOs to sustain a jamming attack becomes expensive. The main concern is privacy: linking payments to on-chain UTXOs could deanonymize senders, undermining the privacy benefits of onion routing.

Reducing HTLC Slot Limits

A pragmatic short-term mitigation: reduce the default max_accepted_htlcs from 483 to a lower value. Eclair already defaults to 30 HTLCs per channel direction, and there is active discussion in the LND project about reducing to approximately 30 to 113 slots. Real-world routing rarely needs more than 30 to 50 concurrent in-flight HTLCs, so the reduced limit has minimal impact on honest users while making slot jamming significantly more expensive.

Risks and Considerations

Fundamental Protocol Tension

Lightning was designed so that failed payments cost nothing. This property is valuable for honest users: pathfinding involves trial and error, and free failures encourage experimentation with routes. Any solution that adds cost to failures changes a core protocol property and risks degrading the user experience for legitimate payments.

Coordination Challenge

Solutions like HTLC endorsement require adoption across multiple implementations (LND, Core Lightning, Eclair, LDK) to be effective network-wide. Partial adoption provides only partial protection, because attackers can route through non-participating nodes. This coordination problem slows deployment even when technical consensus exists.

Privacy Tradeoffs

Several proposed mitigations (stake certificates, reputation tracking) require nodes to learn more about payment senders. This creates tension with Lightning's privacy model, which relies on onion routing and blinded paths to keep payment details confidential. Any solution that improves jamming resistance at the cost of sender privacy may push users toward more centralized custodial services.

Layer 2 Alternatives

The persistence of the jamming problem is one motivation for exploring alternative Layer 2 architectures. Protocols like Spark use different off-chain constructions that do not rely on multi-hop HTLC routing, avoiding the jamming attack surface entirely. Understanding channel jamming helps contextualize why the Bitcoin Layer 2 landscape continues to diversify beyond Lightning.

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.