BIP-110 Nears Mandatory Signaling With Minimal Miner Support

What is happening

Bitcoin is approaching the enforcement phase of BIP-110, a contested soft fork that would restrict certain forms of data storage on the network for about one year. Around block 961,632, expected on or near August 9, 2026, nodes running the BIP-110 software are set to begin rejecting any block that does not signal support for the change.

The proposal, formally titled the Reduced Data Temporary Softfork, was authored by Dathon Ohm and credits an original draft and advice to the developer Luke-Jr. Its stated goal is to limit the size of several data fields at the consensus level in order to discourage large data embeddings such as Ordinals inscriptions.

How activation is meant to work

BIP-110 uses a modified version of the BIP9 signaling method. Miners indicate readiness by setting bit 4 in the blocks they mine, under the deployment name "reduced_data". For a voluntary early lock-in, at least 1,109 of the 2,016 blocks in a retarget period must signal, which is 55 percent.

The proposal does not stop there. During the retarget period from block 961,632 to block 963,647, signaling becomes mandatory for BIP-110 nodes: those nodes reject any block that does not set bit 4. Lock-in follows no later than block 963,648, the rules become active at block 965,664, expected around September 1, 2026, and they expire on their own after 52,416 blocks, roughly one year later.

Where support stands

Miner signaling has remained low throughout the deployment. By late July 2026, monitoring dashboards put support in the low single digits of percent, and no retarget period has approached the 1,109 blocks required for a voluntary 55 percent lock-in. Backing has come mainly from the Ocean pool and smaller independent miners, while large pools have not signaled.

BIP-110 includes a grandfathering rule: coins confirmed before activation can still be spent under the previous rules for the entire deployment. The new limits apply to outputs created at or after activation.

A reported bug in the activation client

On July 17, 2026, a report published at BlockSlop described a reproducible defect in the upgrade path of the Knots-based activation client. According to the report, a node that enables enforcement on an existing data directory can keep a block that a freshly synchronized BIP-110 node rejects. Two nodes running identical rules could therefore disagree about which chain is valid. The report was reproduced on regtest and accompanied by a proposed fix.

Context and what comes next

If signaling stays near current levels when mandatory signaling begins, BIP-110 nodes would reject the blocks produced by most of the network's hashrate and follow only the small number of signaling blocks, which can create a chain split at that point. Developers including Adam Back and Jameson Lopp have publicly warned that the activation parameters risk such a split.

The proposal's author has maintained that BIP-110 already has consensus, a claim critics say is not reflected in the on-chain signaling data. For the mechanics behind the split risk, the unusually low threshold, and what a separate BIP-110 chain would mean, see the deeper read in BIP-110 explained.