BIP110 does not break the Lightning Network at the protocol level: every output and script a standard Lightning channel uses fits within its proposed data limits. The real risk is indirect. BIP110 carries a forced activation at block 961,632, expected in early August 2026, and any contested activation creates chain-split risk that Lightning nodes, which must act on what they see on-chain, are uniquely sensitive to.
Lightning is Bitcoin's payment layer. It settles payments in under a second for fractions of a cent by moving value through channels: two-party accounts funded with bitcoin whose balances update off-chain. Channel security depends on publishing and seeing transactions on the Bitcoin blockchain, so any proposed change to Bitcoin's consensus rules deserves a close read from a Lightning operator's seat. This post gives BIP110 that read.
What is BIP110?
BIP110, the Reduced Data Temporary Softfork, is a proposal to tighten Bitcoin's rules for roughly one year to limit arbitrary data storage in transactions. The specification caps most new output scripts at 34 bytes, allows up to 83 bytes for OP_RETURN (a transaction field for small data payloads), and limits data pushes to 256 bytes. The stated goal is to curb inscriptions and other non-payment data.
Activation works differently from past soft forks. The BIP110 deployment rules activate the fork early if 55% of blocks in a single difficulty period signal support: 1,109 of 2,016 blocks. If that never happens, a mandatory signaling phase begins at block 961,632 anyway, expected in early August 2026, guaranteeing lock-in, with enforcement starting roughly two weeks after that. Nodes enforcing BIP110 then reject blocks that violate the new rules. The restrictions last 52,416 blocks, about one year, then expire automatically.
Here is how the proposed limits compare with what Lightning actually puts on-chain:
| BIP110 rule | Proposed limit | Standard Lightning usage |
|---|---|---|
| New output scripts | 34 bytes max (83 bytes for OP_RETURN) | Channel outputs are exactly 34 bytes |
| Data pushes and witness data | 256 bytes max | Largest channel scripts are under 150 bytes |
| Spendable witness versions | Version 0 and taproot only | Channels use version 0 and taproot |
| Taproot annex, large control blocks | Restricted | Unused by deployed channels |
| Duration | 52,416 blocks (~1 year), then auto-expiry | Temporary by design |
Does BIP110 break Lightning transactions?
No. Every output type a Lightning channel uses today fits inside the proposed limits. Channel funding and commitment outputs are pay-to-witness-script-hash or taproot scripts of exactly 34 bytes, which is precisely the cap BIP110 proposes. The scripts that enforce channel penalties stay far below the 256-byte push limit. And funds in channels opened before activation are exempt from the new input rules entirely.
The details are in Lightning's transaction specification. BOLT 3, the Lightning commitment transaction spec, defines funding outputs as 2-of-2 multisig wrapped in a 34-byte witness script hash, and its largest routine witness scripts, the HTLC scripts that secure in-flight payments, come in under 150 bytes. BIP110 also exempts any coin created before activation from its spending rules, so existing channels could force close (settle their final balance on-chain unilaterally) without hitting the new restrictions.
One operational wrinkle exists on the mining side. Bitcoin Optech's newsletter coverage notes that Bitcoin Core does not enforce BIP110 rules and has no feature to build block templates that exclude the transactions BIP110 treats as invalid. Most of the network would keep operating on the old rules unless a majority of miners changes software.
Why is a chain split the real risk for Lightning?
Lightning's security model assumes your node can see the Bitcoin blockchain. If a counterparty broadcasts an outdated channel state, you have a limited window to respond with a penalty transaction. During a chain split, when two incompatible versions of the blockchain coexist, a node watching the losing chain never sees a theft attempt on the winning one, so that response window can expire unanswered.
This is the scenario critics of BIP110's forced flag day point to. Because nodes enforcing BIP110 reject non-compliant blocks outright after block 961,632, even a small minority of enforcing hashrate could briefly maintain a separate chain. Lightning nodes, watchtowers (services that watch the chain for channel theft on your behalf), and payment processors would each need to know which chain their software follows and whether their channel counterparties follow the same one.
The severity spans a range. At current support levels the likeliest outcome is a fizzle: a handful of enforcing nodes stop following the majority chain and their view of Bitcoin simply stalls. With meaningful enforcing hashrate, a minority chain could persist for days. Either way, a Lightning node never picks a chain itself. It inherits its view from the Bitcoin backend it runs on, so the software your backend runs decides which side of a split you experience.
Routing operators are already positioning for this. Lightning Network Liquidity, a routing-node operator, published a BIP110 transition statement describing its migration plan and framing the decision in economic rather than ideological terms:
As a routing node, we aren't 'voting'; we are positioning ourselves where we believe the economic gravity is strongest.
Lightning Network Liquidity, BIP110 (RDTS) Transition Statement
The practical takeaway is not that channel funds are doomed. It is that the days around activation deserve the same operational caution exchanges apply to any contested fork: fewer irreversible actions, more confirmations, closer monitoring.
What would BIP110 mean for future Lightning development?
BIP110 restricts the taproot annex, larger control blocks, and several tapscript features for its full 52,416-block duration. Deployed channels use none of these today, so nothing running breaks. Proposed upgrades do use them: LN-Symmetry, a simpler channel design that relies on the taproot annex, and channel factories, which amortize one on-chain transaction across many channels, both build on the restricted surface.
Since the restrictions expire automatically after roughly one year, the effect on Lightning research would be a pause rather than a cancellation. Still, a consensus rule that expires can also be renewed, and several Lightning developers have argued that normalizing temporary restrictions on script capabilities raises the cost of building Bitcoin's payment layer. That debate is about precedent, not about any transaction Lightning sends today.
Will BIP110 actually activate?
Almost certainly not on current numbers. In a widely shared analysis, early Bitcoin miner Jason Hughes reviewed the signaling data: only 0.6% of blocks mined over the past 60 days signaled support, while between 7 and 15% of reachable nodes signal it, and he put the odds of success at less than a 5% chance. Bitcoin Core, the software most nodes run, has not adopted the rules.
Hughes also challenged the proposal's core premise, noting that the restrictions do not actually prevent determined data storage:
Byte-for-byte the same contiguous arbitrary data can provably end up stored in the current chain or the BIP-110 chain.
Jason Hughes (wk057), analysis of BIP110, July 2026
Low support does not reduce the flag-day risk to zero, though. The mandatory signaling phase at block 961,632 begins regardless of support, so a small enforcing minority could still split off briefly. You can track block height and miner signaling in real time on a public block explorer, and monitor Lightning network health, capacity, and node behavior through live Lightning network statistics.
How should businesses on Lightning prepare for BIP110?
Treat early August 2026 as a standard contested-fork window and reduce your exposure to actions that depend on immediate chain finality. For most businesses accepting Lightning payments, that means a short checklist rather than an infrastructure overhaul:
- Avoid opening or splicing channels from shortly before block 961,632 until well past activation. Splicing (resizing a live channel with an on-chain transaction) and channel opens both create fresh on-chain footprints during the uncertainty window.
- Require extra confirmations for on-chain deposits in the days around activation, since a brief split elevates reorg and double-spend risk.
- Confirm which rules your Bitcoin backend enforces. A Lightning node inherits its view of the chain from the Bitcoin software underneath it. Bitcoin Core follows the existing rules; only backends running enforcement software reject non-signaling blocks.
- Check your counterparties and watchtower. Channel safety depends on both sides of a channel, and any watchtower you rely on, seeing the same chain.
- Keep your node online through the window. Taking a node offline voluntarily disables your own breach detection exactly when response windows matter most. Uptime is a defense here, not an exposure.
- Hold an on-chain fee reserve. Emergency force closes compete for block space, and fees spike during uncertainty. Spare confirmed funds for fee-bumping help a justice or force-close transaction confirm when it counts.
- Keep normal Lightning payments flowing. Off-chain payments between well-connected, online nodes do not touch the chain and carry the least fork exposure of any Bitcoin transaction type.
If you accept bitcoin or stablecoin payments over Lightning through a managed provider, most of this list is your provider's job. Amboss operates Lightning infrastructure and the network's most widely used explorer, and Amboss Payments handles node operations, channel management, and chain monitoring for businesses so that consensus events like BIP110 become a status update rather than an engineering project. If you run payment volume on Lightning and want that operational load off your team, see how payment providers use Amboss.
Frequently asked questions
Does BIP110 affect Lightning payments directly?
No. Lightning payments settle off-chain and only touch the Bitcoin blockchain when channels open, close, or are spliced. Every on-chain transaction type a standard channel produces fits BIP110's proposed limits: outputs are exactly 34 bytes and channel scripts stay under 150 bytes, well inside the 256-byte push cap. The risk to Lightning comes from potential chain instability during a contested activation, not from the rules themselves.
Do I need to close my Lightning channels before BIP110 activates?
No. Closing channels preemptively creates on-chain transactions during exactly the window you want to avoid them. Coins created before activation are exempt from BIP110's spending rules, so existing channels can close normally afterward under either outcome. The safer play is the opposite: keep channels open, keep payments off-chain, and postpone new channel opens and splices until the activation window at block 961,632 passes.
Will BIP110 cause a chain split?
Miner support sat at 0.6% of blocks over a recent 60-day stretch, so a network-wide rule change is unlikely. A brief minority split remains possible because the signaling phase beginning at block 961,632 guarantees lock-in rather than requiring majority support. If a small share of hashrate enforces the rules, its chain would likely have far less proof-of-work and fade, but the hours or days of uncertainty are worth planning around.
What happens to Lightning funds during a chain split?
Channel balances exist on both chains simultaneously, since both share history up to the split. The danger is visibility: a node following one chain cannot see or respond to a fraudulent channel close broadcast on the other. Operators mitigate this by following the majority-work chain, requiring extra confirmations, and avoiding channel state changes during the window. Funds in channels that stay quiet through the split are the least exposed.
Is BIP110 permanent?
No. The restrictions expire automatically after 52,416 blocks, roughly one year from activation, with no action required. Coins created before activation are exempt from the spending restrictions for the entire period. Supporters describe it as a temporary measure against arbitrary data storage; critics note that a temporary rule can be renewed and object to the precedent. Either way, the design is explicitly self-sunsetting.