The version field has no opinion on narratives. You should understand it anyway.
Track Bitcoin's BIP-110 signal rate. As of August 7, 2025: 2.62% of the last 2,016 blocks. The minimum threshold for lock-in? 55%. The historical standard for Bitcoin soft forks? 95%. The distance to mandatory enforcement? 185 blocks.

This is not a proposal. It is a countdown.
At block 961,632, Bitcoin Knots โ the alternative node implementation maintained by the Luke Dashjr ecosystem โ begins rejecting blocks that fail to carry version bit 4. Bitcoin Core, the implementation that secures the overwhelming majority of network infrastructure, will accept those same blocks. No caveats. No edge cases. Same block, two verdicts, one chain.

The market has priced this at approximately zero. Signal support of 2.62% tells you why: the people who decide which rules constitute Bitcoin have not bothered to signal. And yet an implementation with real deployment is moving toward enforcement anyway.
Liquidity vanishes faster than hype. So does consensus. If you wait for the narrative layer to explain this event, you will be reading about the chain split after the chain has already split.
To understand why BIP-110 is different from every soft fork that preceded it, you need to understand the mechanism that made Bitcoin upgrades safe in the first place.
BIP-9, adopted in 2016, established the version-bit framework. Miners signal readiness by setting bits in the block header's version field. A 95% threshold of hash power over a 2,016-block difficulty period triggers a lock-in, followed by a grace period before activation. The design is intentionally conservative. It requires near-universal miner acceptance, and by extension, near-universal node acceptance, before any rule change takes effect. The assumption: no single constituency can force a rule change on the network. The mechanism: signaling, threshold, activation.
BIP-110 inverts this architecture.
Formally, BIP-110 is a soft fork. It tightens consensus rules around block data compression and SPV verification optimization. The technical goal is modest: compress Merkle path validation data to reduce block weight and accelerate light-client verification. The concept traces a direct line to the SPV proposals from the 2015-2017 block size wars. The innovation is not technical. The innovation is procedural, and it is dangerous.
Three procedural deviations separate BIP-110 from its predecessors.
First: the threshold. BIP-110 requires 55% of hash power โ 1,109 blocks out of a 2,016-block window โ to trigger lock-in. That is a material reduction from the 95% standard, and a direct redefinition of the consensus floor. If 55% becomes the operative standard for Bitcoin upgrades, then every subsequent proposal inherits a weaker consensus requirement. The compounding effect across future rule changes is far more significant than BIP-110 itself.
Second: enforcement without threshold. This is the detail that moves the event from "controversial proposal" to "infrastructure incident." The mandatory signaling period begins at block 961,632 unconditionally. Signal rate, miner support, community consensus โ none of it matters. The enforcement is tied to block height. Execution nodes will begin rejecting non-signaling blocks at that height, whether the threshold is met or not.
Third: the fallback. If lock-in does not occur, the reduced data rules are still scheduled to activate at block 965,664. In other words, the success path and the failure path converge on the same outcome. The threshold is not a gate. It is an ornament. The only real variable is time.
Who is executing this? The evidence points to two coordinated actors. Bitcoin Knots has implemented BIP-110 and published warnings about the dangers of running "non-executing software." OCEAN, the mining pool with roots in the BSV ecosystem, switched its default block production endpoint to a BIP-110-signaling configuration on July 15. Bitcoin Core, meanwhile, closed the BIP-110 implementation pull request on March 26, 2025, and core contributor Antoine Poinsot stated on June 4 that Core does not implement the proposal.
That is the full picture. A node implementation with a deadline. A mining pool with a signaling endpoint. A proposal with 2.62% support. And a clock that runs regardless.
What BIP-110 Actually Changes
Let me be precise about the technical content before analyzing the governance implications. BIP-110 targets the Merkle path validation structure in Bitcoin blocks. It introduces a compression scheme that reduces the data payload required for transaction verification, with the expressed goal of shrinking block data and improving SPV client performance. The proposal positions itself as an efficiency upgrade โ less data, faster verification, no security trade-off.

The concept is not novel. It descends from a lineage of SPV optimization proposals that circulated during the block size wars. The technical community's response has been consistent across the years: the ideas are plausible, the marginal efficiency gains are real but small, and the consensus risk is not worth the benefit. That response explains why BIP-110 never achieved traction as a proposal. What it does not explain is why it is proceeding toward enforcement anyway.
The answer, I believe, is that BIP-110 was never really about block data compression. It is a test of whether a determined implementation team can force a rule change through infrastructure control, independent of community support. That is a much more significant event than any optimization proposal.
Three Deviations from BIP-9 โ The Procedural Breakdown
Let me walk through the activation flow in detail because the deviations are the story.
Under standard BIP-9, the activation cycle has four discrete phases: signaling, threshold achievement, lock-in, and activation. The threshold is unambiguous: 95% of blocks in the difficulty period must signal. The lock-in is automatic once achieved. The activation is scheduled. The system is deterministic and conservative.
BIP-110 replaces this with a conditional structure that decouples enforcement from consensus. The signaling threshold is 55% โ already a deviation โ but crucially, the mandatory signaling period at block 961,632 is not contingent on threshold achievement. Execution nodes will reject non-signaling blocks at that height, regardless of signal rate. If lock-in does not occur, the reduced data rules activate at block 965,664 by default.
The implication is stark: the proposal's activation does not require consensus. It requires only time.
This breaks the foundational soft fork assumption. A soft fork is safe because nodes running older software continue to validate all blocks produced under the new rules โ the old rules are a subset of the new rules. When Knots rejects blocks that Core accepts, not because of the blocks' intrinsic validity but because of a version bit, the safe-upgrade property is destroyed. The soft fork umbrella has a hole in it, and the hole is the version field.
The Divergence Scenario: What Happens at 961,632
Let me simulate the divergence precisely, because the market's intuition about "forks" does not map cleanly onto this event. When people hear "fork," they think Bitcoin Cash, hard fork, exchange listings, and a new ticker. This is not that.
At block 961,632, the network has two rulesets competing for validity. Bitcoin Core nodes โ the overwhelming majority โ accept any block that satisfies the current consensus rules. Bitcoin Knots nodes โ a small minority โ reject any block that does not carry version bit 4. If miners continue producing standard blocks, the Core-validated chain grows normally. The Knots-validated chain stalls at the last compliant block.
But the scenario does not end in a static stall. OCEAN's July 15 endpoint change matters here. If OCEAN is genuinely producing blocks with version bit 4 set, then Knots nodes have a chain to follow โ a chain with 1-2% of total network hash power. At that difficulty, blocks appear irregularly. Each block is a reorg risk for anyone building on it. The economic value of that chain is effectively its accumulated proof-of-work, which at 1-2% of global hash is negligible.
There is a real possibility, though, that OCEAN's endorsement is not what it appears. The pool has historically positioned itself as a "protocol purist" operation, and its public signaling has been ideologically consistent. But BIP-110's signal threshold of 55% was never approached, and OCEAN's hash power is insufficient to reach it even if every block it produced carried the signal. The pool cannot achieve lock-in on its own. What it can do is create a sustained run of compliant blocks, enough to activate the fallback provisions, enough to make the divergence observable.
Observability is the point. If the divergence becomes visible โ if block explorers running Knots endpoints show a different chain state than those running Core endpoints โ the market will be forced to confront a question it has never had to answer. Which chain is Bitcoin? The one with the rules, or the one with the hash power?
Based on my experience analyzing protocol-level events โ including the 2017 0x token sale audit, where the market's focus on hype obscured structural smart contract risks โ I can tell you with confidence: the market answers that question exactly once, and the answer is not determined by technical merit. It is determined by exchange listings, custody provider behavior, and the CME futures reference rate. None of those would recognize a BIP-110-compliant chain as Bitcoin. That is the survivorship advantage of the status quo.
Technical Risk Catalog
Let me now catalog the risks that actually matter, in order of severity.
Risk One: chain stall and node islanding. If Knots nodes reject the main chain and no sustained compliant hash power emerges, those nodes become orphaned. Their view of Bitcoin freezes, diverges, and eventually becomes irrelevant to the network. But "irrelevant to the network" is not "irrelevant to users." Services built on Knots โ I can identify a meaningful subset of privacy-focused wallets and self-custody tools that have historically used Knots builds โ would show inconsistent transaction states. Users would see unconfirmed transactions that the rest of the network considers confirmed. Some of those users would act on that information. That is how disinformation propagates at the protocol level.
Risk Two: upgrade state machine hazards. BlockSlop's regtest reproduction identified a narrow but real issue: switching from a BIP-110-executing node to a non-executing implementation leaves the data directory with blocks accepted under the old rules. On restart, the node does not immediately reconcile inherited history, briefly operating in a state of rule inconsistency. Bitcoin Knots has since merged protective measures โ scanning inherited block headers for mandatory signal violations and invalidating non-compliant blocks. But the patch has a known gap: transaction or script violations that are not visible in block headers require full reconnection verification and potentially a reindex. For a mainnet Bitcoin node, reindexing is a multi-day synchronization process. That is not a theoretical concern. That is a logistics event for every affected infrastructure operator.
Risk Three: the Bitcoin Core compatibility gap. The Core implementation will not enforce BIP-110. That is settled. The consequence is a network running two node implementations with divergent consensus rules. In Bitcoin's history, this has happened before, but always with either a clean chain separation or a concession from one side. BIP-110 has neither. Knots will not abandon enforcement without losing face. Core will not implement the proposal without a governance reversal. The collision course is locked.
The deeper structural concern: Bitcoin's multi-implementation model was always a feature โ the idea that no single codebase controls the network. BIP-110 weaponizes that architecture. An implementation that represents a small fraction of the network can produce a divergence event with significant disruptive potential, simply by enforcing a rule that no one asked for. The cost of entry into the disruption market is far lower than it should be.
Economic Dimensions: Zero Supply Impact, Non-Zero Tail Risk
On tokenomics, the analysis is straightforward. BIP-110 does not modify BTC's total supply, block reward, halving schedule, or issuance curve. It is not a token event by any conventional definition. The economic impact is indirect, and it flows through exactly one channel: the probability of a chain divergence.
Let me price that probability honestly. A persistent chain split requires three conditions: sustained compliant block production by OCEAN, sustained enforcement by Knots nodes, and a failure of all coordination mechanisms that have historically resolved such disputes. Each condition individually is plausible. The conjunction is not. I estimate the probability of a persistent, economically meaningful chain split at well under 5%.
But tail risk pricing is not about the expected value. It is about the preparedness gap. If the divergence does materialize, the market response would be a brief spike in volatility, a scramble by exchanges and custodians to clarify which chain they recognize, and a regulatory inquiry into Bitcoin's infrastructure robustness. None of that is fatal. All of it is repricing. And none of it is priced today.
I have seen this pattern before โ most acutely in the Terra-Luna collapse of 2022. When UST began its depeg, the market had priced the entire stablecoin complex as risk-free. The collapse moved faster than any risk framework could react. I liquidated 60% of our high-risk altcoin holdings within hours, not because I knew the outcome, but because I knew the market's pricing was wrong. The BIP-110 situation is not analogous in magnitude, but it is structurally similar: a low-probability event with a discontinuous downside path, trading at zero implied probability.
My assessment of market impact: if the divergence remains contained within technical circles, Bitcoin price impact will be under 1%. If the divergence becomes visible at the infrastructure level โ block explorers showing conflicting data, exchanges pausing BTC deposits, CME reference rates questioned โ the impact range shifts to 2-5% with elevated volatility for days. The trigger for the second scenario is not the chain split itself. It is the observable divergence.
Don't trust the yield; audit the source. And in Bitcoin, the source is the consensus. Audit it before the next countdown starts.
Ecosystem Fault Lines: Who Breaks First
The ecosystem map is both simple and revealing. Upstream: miners. The overwhelming majority of hash power continues producing standard blocks with unchanged economic incentives. OCEAN is the only meaningful exception, and its decision to pre-signal on July 15 suggests a level of coordination with the Knots development team that cannot be dismissed as coincidence.
Midstream: node implementations. Bitcoin Core carries the network's consensus weight. Bitcoin Knots carries the enforcement action. The divergence between them is the crux of the event. What most analysts are missing is the downstream consequence: any infrastructure provider running Knots โ or any provider using a data source that runs Knots โ inherits the divergence. Block explorers, payment processors, custody systems, and indexers are the silent victims of this event.
I can already see the warning signs in the developer ecosystem. The BlockSlop reproduction is not an academic exercise. It is a practical demonstration that the upgrade path between consensus states is not safely reversible. The fact that Knots moved quickly to patch the header-scanning gap demonstrates that the developers understand the severity. What they have not demonstrated is a solution for the transaction-level verification gap, which requires either a full reindex or a trust assumption that violates Bitcoin's security model.
There is also a regulatory angle that the crypto-native media is ignoring. If this event produces any visible infrastructure failure โ a delayed withdrawal, a brief exchange halt, a mismatched block explorer โ the incident becomes evidence in a growing regulatory file about Bitcoin's "decentralization promises." From my work integrating institutional digital asset custody under MiCA frameworks in Brussels, I can tell you that European regulators watch events like this with a specific question in mind: is Bitcoin infrastructure sufficiently robust to qualify as a regulated financial asset class? Every infrastructure divergence is a data point against the maturity thesis. That is the quiet risk that compounds with each failed coordination event.
Now the uncomfortable thesis that most coverage will miss.
The contrarian position is not that BIP-110 will succeed. It will fail. The contrarian position is that BIP-110's failure is precisely what makes it valuable โ and dangerous.
Here is the value: BIP-110 is a full-scale test of Bitcoin's resistance to unilateral rule changes, conducted in conditions where the attacker is weak. The signal rate is 2.62%. The mining support is negligible. The exchange and custody infrastructure is aligned against the proposal. If Bitcoin's consensus survives under these conditions โ and it will โ that survival is not evidence of the system's strength. It is evidence of the attacker's weakness.
The danger is the inverse. Future attempts will not have a 2.62% signal rate. Future attempts will have coordinated exchange support before the block height. Future attempts will have a mining coalition behind them, not a single pool. The playbook that BIP-110 is writing โ block-height-based enforcement, unconditional signaling periods, fallback activation clauses โ is the playbook for a far more serious attack on Bitcoin's governance model.
Let me be direct about the entity-level question. The evidence strongly suggests Bitcoin Knots maintainer Luke Dashjr is the driving force behind BIP-110, and that OCEAN's coordination with the Knots development team predates the July 15 endpoint change. This is not an organic, bottom-up consensus event. It is a directed, top-down infrastructure action. The proposal itself is a convenient vehicle for a governance experiment: can a rule change be forced through implementation control rather than community consensus?
The answer, based on every signal we have, is no. But the experiment is still running. And the asymmetry between the cost of attempting it and the cost of defending against it is the most important structural insight of this event. The attacker needs one node implementation and one mining pool. The defender needs the coordinated response of every exchange, custody provider, and regulatory authority. That asymmetry will not escape the attention of better-resourced actors.
The institutionally uncomfortable question is this: can a one trillion dollar asset have two competing rulesets with no governance mechanism to resolve the conflict? For the first time, the answer is not an obvious yes. BIP-110 does not threaten Bitcoin's price. It threatens Bitcoin's claim to be a mature, governable financial asset. The market will not reprice the event until the infrastructure layer demonstrates its coordination capacity. That demonstration, not the block height, is the variable to watch.
Here is what I will be watching after block 961,632, in order of importance.
First: OCEAN's block production. A sustained run of bit-4-signaled blocks is the only event that can make the divergence visible.
Second: Knots node synchronization status. If monitoring services report stalled or diverging nodes, the infrastructure problem is real.
Third: CME and ETF funding rates. Any anomaly in the traditional market's derivatives pricing indicates the narrative layer has caught up with the technical layer.
Positioning advice from a fund manager's desk: this is not a directional event. It is a volatility event. Maintain BTC exposure, but consider a modest tail-risk hedge into September. The probability of meaningful disruption is low. The probability that the market prices it at zero is, as we have established, certain.
Bitcoin will survive BIP-110. The network is resilient because its consensus is a process, not a code constant. But the next challenge to that process will not signal at 2.62%. It will coordinate before it deploys. The algorithm does not read the news. It reads the rules. And right now, the rules are not aligned.