The 3% Signal: BIP-110's Mandatory Signaling Was a Governance Coup Dressed as Code

Here's the number that tells you everything: 3%. That's the miner signaling support for BIP-110's mandatory signaling phase at launch. Not 30%. Not 13%. Three percent of network hash power bothered to send the version bit the protocol demanded. The rest stayed silent. The rest, functionally, were the network.

Math doesn't negotiate. When fewer than 3% of miners signal for a rule nodes are supposed to enforce, you're not looking at a protocol upgrade. You're looking at a standoff.

What BIP-110 Actually Proposed

BIP-110 wasn't a scaling solution. It didn't adjust block size, transaction fee logic, or confirmation time. It was a deployment mechanism — a meta-rule governing how Bitcoin's consensus layer accepts or rejects future changes.

The proposal introduced mandatory signaling: after a defined window, full nodes running the updated client would reject any block lacking a specific version field. No 95% hashpower threshold. No extended discussion period. A deadline, then rejection, enforced by node operators rather than miners.

This places BIP-110 in the user-activated soft fork (UASF) lineage — the philosophy that economic nodes, not hashpower, hold ultimate authority over protocol changes. Elegant in theory. Nodes enforce. Miners comply. Upgrade complete.

Reality diverged. At the mandatory signaling phase, miner support sat below 3%. This wasn't a close race. It was a rout.

The episode landed in a specific historical window. Between 2015 and 2017, Bitcoin was consumed by the blocksize debate. Core developers advocated for SegWit and layered scaling. A coalition of miners and large-block proponents pushed direct blocksize increases. BIP-110 wasn't introduced in a vacuum. It was a shot in that war.

The Node-Miner Divergence Problem

The core tension is structural. Miners produce blocks. Nodes validate them. Normally these roles align — miners upgrade, nodes upgrade, the network transitions. Mandatory signaling breaks that symmetry by design.

Here's what actually happens when enforcement and production diverge:

1. A minority of miners — say, 3% — produce blocks carrying the new version bit.
2. These blocks propagate across the network.
3. Nodes running the mandatory signaling client accept only these blocks.
4. The other 97% of blocks from non-signaling miners get rejected.
5. The network splits into two consensus views: one that follows the 3%, one that follows the 97%.

This isn't hypothetical. It's the mechanical consequence of the ruleset. The 'mandatory' in mandatory signaling isn't a handshake — it's a filter. When a filter rejects the overwhelming majority of a chain's production, you get a fork, a chain stall, or a reorg. None of those outcomes favor a store-of-value asset.

Compare this to BIP-9, the mechanism Bitcoin settled on. BIP-9 requires 95% of hashpower to signal readiness over a defined period. No threshold, no activation. If miners don't want the upgrade, the upgrade doesn't happen. The risk of chain split drops dramatically because the people who produce the blocks are the people who approved the change. It's a consensus mechanism that starts with consensus.

BIP-110 inverted this logic. It placed enforcement power with nodes and the compliance burden on miners, assuming node authority would override miner resistance. The 3% number demonstrates how wrong that assumption was.

What that number actually measures is coordination failure on both sides. The miners who signaled were early adopters or Core-connected. The 97% made a collective decision — by action or inaction — that the upgrade wasn't worth compliance. In game theory terms, this is a coordination problem with a hawkish minority and a passive majority. The result: a stable but hostile equilibrium. No fork. No upgrade. No change.

There's also an economic reading the technical analysis often misses. Miners support upgrades when those upgrades improve their bottom line — lower orphan risk, better fee markets, cheaper validation. BIP-110 offered none of that. It changed how activation decisions were made, not how mining revenue was generated. From a miner's perspective, signaling meant incurring upgrade costs — software changes, coordination overhead, potential chain disruption — for zero additional revenue. That's not a mystery. That's rational indifference wearing the mask of opposition.

A Test With a Pre-Written Failure Plan

The most revealing detail is the 'hard fork rollback' discussion. A rollback path existed before the mandatory window even opened. That tells you something: the developers knew. They knew miner support was inadequate. They knew the enforcement mechanism could fail. And they built the escape hatch anyway.

This transforms the framing. The mandatory signaling phase was never a serious attempt to activate a protocol change. It was a pressure test — a controlled experiment measuring whether node-side enforcement could bend miner behavior. The rollback plan bounded the downside. The signal they were measuring was miner willingness to comply under threat of rejection.

The result: miners didn't blink. Three percent compliance is not a negotiation outcome. It's a refusal.

I've spent years auditing smart contracts and consensus mechanisms. Principal-agent problems sit at the core of almost every failure I've analyzed. The LUNA death spiral wasn't an oracle bug — it was an incentive misalignment between protocol promises and bank run realities. BIP-110 is the same pattern at the governance layer. The developers' authority to write code does not imply the miners' incentive to run it. Code is law, but bugs are reality — and here, the bug was the assumption that enforcement alone creates compliance.

What the Historical Record Actually Shows

Conventional history records BIP-110 as a failed experiment superseded by BIP-9. I think that's incomplete.

BIP-110 wasn't superseded for technical inferiority. It was superseded because the conflict it addressed was political, not technical. The 2015-2017 blocksize war pitted a developer-led vision for Bitcoin against miner-aligned scaling interests. BIP-110 was a weapon in that war — a mechanism designed to let the node side win a fight it couldn't win through hashpower.

The proof? BIP-9 doesn't just lower risk. It explicitly concedes the core question: miners get veto power over protocol changes. That's not a natural consequence of superior engineering. It's a peace treaty. Bitcoin's subsequent soft forks — SegWit's activation saga, Taproot's smooth deployment — all ran through BIP-9's negotiated framework. The market-signaling, miner-ratifying model became canonical not because it was elegant, but because it was survivable.

The unflattering reading: BIP-110 was a coup attempt dressed as a technical proposal. The 3% miner support shows how completely that attempt failed. And the absence of real consequence — no fork, no chain split, just a quiet rollback — shows Bitcoin's governance absorbed the attack without structural damage.

There's an irony worth noting. The same idea resurfaced in 2017. BIP-148 — the infamous UASF proposal — revived mandatory signaling to force SegWit activation against miner resistance. The difference: BIP-148 had real community coordination. Users organized, exchanges prepared, and the economic majority signaled intent. Miners, facing a credible fork threat, finally moved. SegWit activated. BIP-110 was the failed dress rehearsal. BIP-148 was the production where the actors bothered to show up.

The Blind Spot Nobody Discusses

Here's the counterintuitive angle: the 3% support figure may not represent active miner opposition at all. It could represent the silent majority — mining pools that never upgraded their software, never voted, never even noticed. The version signal requires a client update. If default mining software didn't include BIP-110 signaling, non-upgraded miners simply produce non-signaling blocks. That's not resistance. That's absence.

In 2021, when I traced the Anchor Protocol's depeg mechanics, I found the same pattern. The catastrophic failure wasn't driven by malicious actors but by unattended default configurations and unpatched oracle code. Markets treat silence as apathy, but in infrastructure systems, silence is often neglect.

The takeaway from BIP-110 is not 'node enforcement fails.' It's 'node enforcement fails without economic coordination.' A mandatory signal only works when the full node ecosystem is prepared to sustain a fork, explain it to users, and force exchanges to pick a side. That requires community mobilization, not just client code. And that mobilization never materialized in 2015.

There's a second blind spot worth naming. If the 'test' was meant to measure miner responsiveness to node pressure, the experiment succeeded. It produced a clear, quantitative result. That result — 3% — became the evidence that retired the UASF approach for almost a decade. Seen this way, BIP-110 wasn't a waste. It was an expensive but effective probe into where power actually sits in Bitcoin governance.

The Archive That Keeps Echoing

BIP-110 is archived, but its logic never left. Every time someone proposes a client-side enforcement mechanism for a contested upgrade, they're reaching for the same lever. The question is whether the ecosystem remembers the 3% answer.

Bitcoin's governance won that fight by absorbing the failure without a split. But the tension between node authority and miner production remains — coded into the protocol's DNA, turning every contentious upgrade into a test of political will.

Privacy is a feature, not a bug. So is the friction that stopped BIP-110's forced activation from tearing the network apart. Next time someone proposes mandatory signaling, check the miner support numbers first. Then ask who defined the rollback plan. The answer will tell you whether it's a technical proposal — or a political one wearing a BIP number.