Bitcoin BIP-110 Signaling Hits 2.64% as August 9 Deadline Nears

Bitcoin's BIP-110 proposal recorded 2.64% miner signaling as of 8:40 a.m. EDT on July 27, 2026, with block 961632 approaching around August 9, 2026. The proposal targets Ordinals-style inscriptions and oversized OP_RETURN payloads through temporary transaction data limits. Ocean mining pool and smaller independent operators lead signaling activity, while major pools including Antpool, ViaBTC, and F2pool have not moved to support the measure. BIP-110 uses a modified BIP-9 activation process that includes a mandatory signaling window starting at block 961632, during which nodes enforcing the proposal will reject blocks lacking version bit 4 regardless of proof-of-work, creating potential for competing chains if broad miner support does not materialize before the deadline.

BIP-110 Signaling Reaches 2.64% as Deadline Approaches

At 8:40 a.m. Eastern time on July 27, the chain tip stood at block 959842. Roughly 1,790 blocks remain before block 961632, the point where nodes running BIP-110 software begin rejecting blocks that do not signal version bit 4. At Bitcoin's average ten-minute pace, that height should arrive on or around Aug. 9, 2026.

BIP-110, formally called the Reduced Data Temporary Softfork, proposes limiting the size of certain data fields used in Bitcoin transactions. The rules primarily target Ordinals-style inscriptions, oversized OP_RETURN payloads, and similar data-heavy uses while leaving ordinary finance-centric bitcoin transfers, key-path Taproot spends, and standard Lightning channel operations unchanged. If activated, the restrictions begin at block 965664 and expire automatically after 52,416 blocks.

Signaling has climbed from below 1% several weeks ago into the 3% range. Ocean continues to account for most of the signaling activity. The rest of the hashpower comes from independent miners and smaller operators including Roughnecks, SoV, BIP110 Generic, Barefoot Mining, 234 Alberta, 888, Peer to Peer Money, Black Jade Advisors, Sazmining, Crestmont Fabrics, Datum Miner, SpammersGFY, Moonwalk, PyBLOCK-Datum, Just For Krypto, and JAMIN.

Foundry, Antpool, ViaBTC, and F2pool, the four pools responsible for most of the network's hashrate, have shown little movement. The only implementation enforcing the proposal is a Bitcoin Knots fork. Reachable nodes running that software stand at around 22% today.

Foundry Implements Client Hashrate Voting System

Around July 17, 2026, Foundry asked customers to vote on whether the pool should begin signaling for BIP-110. The company tied the outcome directly to its clients' hashrate, according to an email sent to pool participants.

"The voting window on Foundry USA Pool™ will be open through the signaling window close date, ahead of block 961,632," Foundry USA pool wrote on its BIP-110 resource page.

Voting power is based on each customer's average hashrate. Clients who do not respond are automatically counted as "No," and Foundry's default position remains to signal against the proposal. Only if "Yes" votes exceed 51% of participating weighted hashrate will the pool switch all of its blocks to signaling support.

Foundry represents between roughly 23% and 33% of Bitcoin's global hashrate, depending on the measurement period. As of July 27, 2026, there has been no indication that a shift has occurred.

Foundry's client resource page links to the BIP specification, the original bitcoin-dev discussion, criticism from Jameson Lopp, and commentary from Adam Back, Michael Saylor, Luke Dashjr, and others.

Mandatory Signaling Window Creates Rejection Mechanism at Block 961632

Once block 961632 arrives, nodes enforcing BIP-110 will reject blocks mined by most of the network because they lack the required version bit. Those nodes will instead follow the relatively small number of signaling blocks.

Legacy nodes will continue accepting both signaling and non-signaling blocks while following the chain with the greatest accumulated proof-of-work. Several independent observers have built dedicated monitoring sites that track activation parameters, with some simulating how the process could unfold under different scenarios.

The monitoring site BIP110 Situation Monitor models a range of possible outcomes during the mandatory signaling window. Its simulation page lets users adjust variables, including the percentage of network hashrate expected to support BIP-110. One simulation with 25% hashrate dedicated to BIP-110 results in a chain split.

The chain recognized by Bitcoin Core and mined by the overwhelming majority of hashrate would continue producing blocks at its normal pace. A minority chain consisting only of signaling miners would advance much more slowly until reaching its next 2,016-block difficulty adjustment.

BIP-110 Activation Path Differs from Segwit and Taproot

BIP-110 follows a deployment path that differs from Bitcoin's two most recent major soft forks. The proposal launched on Dec. 1, 2025, using a modified BIP-9 process. It required 1,109 of 2,016 blocks, or 55%, signaling during a single difficulty period to lock in early. If that threshold was never reached, the proposal advances toward a forced lock-in at block 963,648 before activating one difficulty period later at block 965,664.

From block 961,632 through 963,647, nodes enforcing BIP-110 reject every block that does not signal version bit 4, regardless of how much proof-of-work supports it. That approach differs from both Segwit and Taproot, where non-upgraded nodes continued accepting the strongest proof-of-work chain throughout activation.

The closest historical comparison is the 2017 BIP-148 user-activated soft fork (UASF), which also attempted to pressure miners through mandatory signaling requirements. That confrontation ultimately ended without a lasting chain split after sufficient hashrate shifted before the deadline.

Proposal Targets Inscriptions and OP_RETURN Payloads

BIP-110 was authored under the name Dathon Ohm. Earlier versions circulated under the BIP-444 designation before being accepted into the BIPs repository.

Supporters argue that inscriptions, BRC-20-style tokens, and increasingly large OP_RETURN payloads raise the cost of operating a full node, distort Bitcoin's fee market, and shift network resources away from Bitcoin's intended purpose as a payment and settlement system.

"Removing rules is a hardfork," BIP-110 supporter and Bitcoin Knots developer Luke Dashjr explained on X in early July. "That includes scheduled rules like subsidy halvings, and yes, even BIP110. Rejecting BIP110 is a contentious hardfork attempt." Dashjr added: "And unlike softforks, hardforks need consensus to succeed. There is no consensus on rejecting BIP110."

Opponents generally agree that spam exists but disagree over whether BIP-110's activation mechanism is the appropriate solution. "OP_RETURN blockspace usage hasn't increased much since Bitcoin Core v30 was released. Oversized OP_RETURNs may be up slightly, but still they consume less than 0.1% of blockspace," Alex Thorn, Galaxy Digital's head of research, wrote on X. Thorn continued: "BIP-110 is an extremely disruptive & dangerous response given the tiny impact from these prunable [transactions]."

FAQ

What is BIP-110 and when does its mandatory signaling window begin?

BIP-110, formally called the Reduced Data Temporary Softfork, proposes limiting the size of certain data fields used in Bitcoin transactions, primarily targeting Ordinals-style inscriptions and oversized OP_RETURN payloads. The mandatory signaling window begins at block 961632, expected around August 9, 2026, during which nodes enforcing BIP-110 will reject blocks that do not signal version bit 4.

How much miner support does BIP-110 have as of July 27, 2026?

As of 8:40 a.m. EDT on July 27, 2026, BIP-110 signaling sits at approximately 2.64%. Ocean mining pool and smaller independent operators lead signaling activity, while major pools including Foundry, Antpool, ViaBTC, and F2pool have not moved to support the proposal. Reachable nodes running BIP-110 enforcement software stand at around 22%.

How does Foundry's voting system for BIP-110 work?

Foundry implemented a client hashrate voting system around July 17, 2026, where voting power is based on each customer's average hashrate. Clients who do not respond are automatically counted as "No," and Foundry's default position remains to signal against the proposal. Only if "Yes" votes exceed 51% of participating weighted hashrate will the pool switch all of its blocks to signaling support.