BIP-110 FORK MONITOR
LOADING ⚠ CHAIN SPLITThe Reduced Data Temporary Softfork signals on version bit 4 and needs 55% of a 2,016-block period. From block 961,632 a block without the signal is invalid under BIP-110 rules while staying valid under everyone else's — if any hashpower enforces while the majority does not, the network splits into two chains. This page tracks miner signaling, node adoption, and both chains live.
/api/v1/blocks; block age from the block's own timestamp.
001) with bit 4 set. Lock-in needs 55% (1,109). Max attainable assumes every remaining block signals.
Source
block heights from both chains — mempool.space (legacy) and fork.observer's header tree (enforcing)
Method
Blocks each chain has added since the last common block. Counted from tip heights, so it stays exact even when no explorer follows the enforcing chain.
Why this replaced signaling
Once the chains separate, "% of blocks signaling" is a statistic about the LEGACY chain, and it reads ~0% precisely because the miners who would signal are mining the fork instead. The fork's own blocks are 100% signaling by construction — a non-signaling block is invalid there — so the measure counts the split as absence of support. Blocks actually mined on each chain is the same question without that trap.
/mining/hashrate/3d × period signaling %
Method
Network hashrate × share of period blocks signaling — a proxy that assumes signaling share of blocks ≈ signaling share of hashrate (unbiased over a full period, noisy over short windows).
Source
OCEAN's BIP-110 pool endpoint — its own telemetry at 10-minute resolution, read against the fork's inherited difficulty (T = D·2³²/H)
Method
Hashrate pointed at the enforcing chain, measured at the pool. The block-count estimate (blocks found since the split × difficulty) is shown beside it on the sub-line.
Why the pool figure leads
A block count is chain-wide and unbiased but it is a window average: a chain whose hashrate collapses keeps reporting the average across the collapse for as long as its window stays open, and at two blocks its 1σ error is around ±70%. This registers a collapse in ten minutes. Every forward-looking number on the page — next block, reward maturity, difficulty relief — runs off it.
⚠ One pool, not the chain
OCEAN operates the BIP-110 endpoint and is believed to carry most or all of the fork's hashrate, but most is not all. Treat it as a floor on the chain's total, which makes every ETA derived from it a ceiling.
(version >> 29) == 001 and bit 4 set. Cross-checks the period tally above.
Source
timestamp of the enforcing chain's tip — fork.observer header tree, corroborated by forkmonitor
Method
Wall-clock time since the fork last produced a block, beside its average interval since the split. A minority chain inherits the difficulty it forked from and cannot retarget for 2,016 blocks of its own, so its blocks arrive at roughly 600s ÷ share — long gaps are expected, and only their growth says the chain is dying rather than slow.
Why this replaced the recount
The rolling 144-block recount measured the legacy chain, where signaling is now settled at 0% and stays there. Whether the fork is still being mined is the live question.
f of hashrate finds blocks every 10 / f minutes (legacy: 10 / (1−f)). Each row measures f as the bit-4 share over a different trailing window — longer windows are steadier, shorter ones catch momentum.
if enforcement began now · inherited difficulty
| Hashrate window | Signaling | BIP-110 EH/s | BIP-110 block time | blk/day | Legacy block time |
|---|---|---|---|---|---|
| loading… | |||||
f (its hashrate share). The chance BIP-110 ever takes the work lead from a deficit of d blocks is the gambler's-ruin bound P = (f/(1−f))^(d+1); the expected deficit after N blocks is N·(1−2f). An overtake would wipe out the legacy chain (BIP-110 blocks are legacy-valid).
Caveat
Constant-hashrate model. The real risk variable is f changing (a large pool flipping) — watch the signaling trend, not just this table.
f from the 1,008-block window
| Race state | Expected legacy lead | P(overtake, ever) |
|---|---|---|
| loading… | ||
consensus.h (COINBASE_MATURITY = 100) · block counts from chain heights · pace from OCEAN's BIP-110 pool telemetry, banded against the blocks found since the split
Method
A coinbase may only be spent in a block at least 100 higher than the one that created it (nSpendHeight − nHeight ≥ 100), counted on its own chain. The first post-fork block sits at fork + 1, so its reward matures exactly when the fork chain has mined 100 blocks of its own. Both chains still carry the difficulty they split from, so that chain's block interval is T = D·2³²/H.
Which H, and why it matters
The counts here are facts; every ETA is a forward projection, so it runs off the hashrate on the fork now rather than the average since the split. Those two disagree by more than 10× during a collapse — a block count is a window average and keeps quoting the pre-collapse pace until its window rolls past it — and the difference is the difference between 35 days and 1.4 years to a spendable coin. The current reading leads and the other end is shown beside it.
⚠ The retarget is the bigger number — and bigger than it looks
A fork inherits the difficulty it split from and cannot adjust until it reaches the next retarget height. Worse, one retarget can only ease difficulty 4×: Core clamps the period's measured timespan to [target/4, target×4], so a chain running hundreds of times slow needs several consecutive periods before its blocks come at ten minutes again. Slow blocks do not self-correct — maturity is the optimistic half of the story.
Not counted
Fees (unknowable from block counts) and whether a matured coin has any market value — that is the fork-coin panel's question, not this one.
—
/api/1/data.json and /api/1/stale.json
Why this is different
Every other source on this page is an explorer: it reports the chain one operator's node follows. These are individually-configured full nodes reporting what they think of every competing tip — including tips they mark invalid. Differing explorer tips show that chains diverge; a node rejecting a branch shows why: a consensus rule refused it. One tracked node runs Knots with -consensusrules=rdts, i.e. it actually enforces BIP-110.
Method
Nodes are grouped by the tip they consider active. A node is only counted as enforcing on confirmed evidence (its run-flags or a Knots build ≥ 20260508) — a node merely named "BIP-110" is labelled, not verified. Split is declared only when the two sides hold different tips; a single lagging node is propagation, not a fork.
⚠ Not a node census
This is one operator's fleet, so it measures validity, not population. Network-wide node share is in the Pools & nodes panel.
—
bits → target, then check SHA256d(header) ≤ target.
A block whose hash no longer satisfies its own target means that chain stopped
validating with SHA256d. Corroborating signal: difficulty discontinuities —
Bitcoin only retargets on 2016-block boundaries, clamped to [0.25×, 4×], so a
reset outside those rules is itself a rule change.
Sources
Raw headers from mempool.space
and kilombino;
verification is done here, so no third party has to be trusted for the verdict.
Threat status — read live from the implementation loading…
| loading… |
target <<= 20 — the
÷1,048,576 drop the header detector tests for as a
signature, alongside the per-block target check. That constant is read from the same
source file, so if it moves upstream this page reports the mismatch instead of
silently testing for the wrong number. Blocks reaching back past the change are
rejected by that code as pow-reversed, so it is one-way.
/api/v1/blocks, incrementally cached server-side
Method
One tile per block, newest first; green = BIP9 bit-4 signal recomputed from the raw nVersion. Hover a tile for height, pool and age; click to open the block.
newest first · click to open
| Period | ~Start | Signaling | % | Δ | vs 55% |
|---|---|---|---|---|---|
| loading… | |||||
/v1/blocks (coinbaseSignatureAscii), read straight off the
block — the miner's own self-declaration on chain. Window is the last
2,016 blocks (one retarget period, ~14 days). Consistency is measured against
the blocks a miner actually found, never wall-clock: a miner with 1% of
hashrate goes days between blocks without having changed anything.
⚠ Limits
A coinbase tag is self-reported and unauthenticated — one operator can run
several, and two tags may be the same farm. Absence of a tag is not evidence of
absence: pools other than Ocean publish none, so their blocks stay at pool
granularity. NEW is only claimed once every earlier signaling block in that
pool has been read, so it never reflects our own backfill order.
/mining/pools/1w (block share) ·
mainnet.observer per-pool BIP-110 signaling CSV, by 0xB10C
Method
Pools matched across sources by normalized name. "Signaling" = the pool has mined at least one bit-4 block since March 2026.
⚠ The two block columns cover different spans
"Blocks" is the last 7 days only. "BIP-110 blocks" is cumulative since the pool's first bit-4 block (March 2026 onward), so it is routinely the larger number — it is not a subset of the 7-day count.
share & blocks = last 7 days · BIP-110 blocks = all-time since Mar 2026
| Pool | Sharelast 7 days | Blockslast 7 days | BIP-110 blocksall-time, since Mar 2026 | Stance |
|---|---|---|---|---|
| loading… | ||||
Consensus tracking COST-TO-FAKE WEIGHTS
There is no vote. Every figure below is a proxy weighted by one question: how expensive is this signal to fake? BIP-110 poses two questions that would be wrong to collapse into one number, so both are scored separately.
Why it is built this way
Bitcoin has no mechanism that counts anyone's preference, so nothing here can be measured directly. A social post is free. A signaling node is a $1 VPS. A miner's version bit costs no hashrate and can be withdrawn inside one block. Hashrate actually committed to a minority chain costs the block reward it gave up. Signals are therefore weighted by cost to fake × power to enforce, and the full ladder is published below so the weighting can be argued with rather than taken on trust.
The two questions: whether the rule becomes Bitcoin's needs an overwhelming supermajority across every constituency. Whether a minority BIP-110 chain survives with real value needs only a coalition — some hashrate, some nodes, one venue willing to quote a price. A single index would answer neither.
How a fork actually resolves — and in what order The claim Miner signaling is a lagging indicator, not a leading one. In 2017 SegWit2x carried 80%+ miner signaling and collapsed below 10% once the Bitfinex BT1/BT2 futures priced B2X at roughly 1% of BTC. Miners followed the money. Consequence for this page The miner pillar is capped at a quarter of the index, and the phase-adaptive scheme moves weight toward whatever has become expensive to fake at that point in the event. Sources SegWit2x (Bitcoin Wiki) · Economic majority 10 steps · lead times are indicative, not scheduled
Cost to fake — why the weights are what they are Method Signals ranked by what it costs to manufacture one. The index weights are derived from this ordering crossed with how directly each constituency can enforce an outcome — not from how easy the data was to obtain. Why rung 1 is excluded Social sentiment is the cheapest signal on the ladder and the hardest to measure defensibly. Including it would contaminate the credibility of everything above it, so it is tracked nowhere on this page. 8 rungs · cheapest to fake at the top
data/bip110_positions.json. No machine-readable feed of
exchange, custodian or wallet policy exists, so the honest options are a
linked and dated register or nothing at all. Precedent:
coin.dance/poli
tracked company support for the 2017 proposals the same way.
⚠ Silence is not opposition
no statement means we looked on the date shown and found no
public policy. It scores zero, but it is reported as coverage rather than
counted as a “no”.
Miners are absent on purpose
Pools are measured live from block versions and mainnet.observer. Listing
them here too would count one coalition into two pillars.
Every tracked entity, its position and the evidence
Consensus tracking — methodology, objections and references
Defining consensus. “Consensus” means three different things that get conflated: the rules each node enforces (binary, per node); the process by which those rules change (no formal mechanism — measurable only by proxy); and the outcome, meaning which chain keeps the name, the ticker and the liquidity (observable only afterwards). This section measures the second by proxy and forecasts the third. The working definition: the degree to which parties who can unilaterally impose costs on a rule change have committed to it, weighted by costly revealed action rather than by statements.
Who counts, and what power they hold. Validators refuse blocks — but crawlers see only reachable listening nodes, while the economic nodes that decide what “valid” means for real value (exchange, custodian and ETF validation) sit behind firewalls and are counted by nobody. Miners choose which chain to extend; signaling is talk, mining is commitment. Exchanges and custodians assign the ticker and provide the liquidity — historically the decisive constituency. Holders set the price, which is what miners and exchanges end up following. Wallet and infrastructure maintainers decide which chain most users follow without ever making a choice. Developers propose; they cannot activate anything.
Known objections, stated rather than hidden. Goodhart's law — a published index becomes a target, and the node pillar is the cheapest to move; that is why the raw-versus-deduplicated spread is the headline uncertainty rather than a footnote. False precision — every figure is a band, nothing carries a decimal it has not earned, and each pillar carries an evidence chip. Arbitrary weights — the OECD handbook is blunt that weighting is a value judgement whatever method is used, so all three schemes ship and the headline visibly moves between them. Legitimacy laundering — a score out of 100 implies a vote exists. It does not. This is an evidence tracker, not a ballot.
Why two scores. BIP-110 is a user-activated soft fork with mandatory signaling: from block 961,632 blocks without a bit-4 signal are invalid under BIP-110 rules bit 4. So the relevant threshold is not 51%. Whether the rule becomes Bitcoin's needs a supermajority; whether an enforcing chain merely exists needs only some hashrate, some nodes and one venue. Reporting one number would answer neither question.
References. Economic majority · Bitcoin is not ruled by miners · Consensus rules · SegWit2x and the BT1/BT2 futures · UASF working group (BIP-148) · Coin Dance political & company support · OECD handbook on constructing composite indicators · BIP-110 / RDTS integration in Knots · bip-0110.mediawiki
Data sources feeding the pillars. btcnodes.io crawler and this site's Node Census deduplication ladder (enforcement) · raw block versions via mempool.space, bip110monitor.com and mainnet.observer (production) · Predyx prediction markets and a CoinGecko/CoinPaprika spot-listing scan (market) · the curated register above (custody, infrastructure, implementation). Index history is recorded here every 30 minutes and cannot be backfilled — the series starts when this page started recording it.
If the chain splits — what actually breaks
BIP-110 is a soft fork: it only takes away things that used to be allowed, so upgraded and non-upgraded nodes keep following the same chain right up until a miner publishes a block the other side considers invalid under its own rules. From that moment there are two Bitcoins with a shared history, and the three problems below switch on at once. They are not predictions — nothing here says a split is likely. They are structural consequences of how this particular deployment was written, and they are the reason this page tracks two chains instead of one. As Bitcoin Optech puts it, any time different nodes enforce different rules there is a risk that blocks are followed by some nodes and not by others. Each card opens into a plain-language explanation.
In plain terms
After a split you own the same coins twice — once on each chain. The trouble is that both chains speak an identical language, so a payment you sign is a perfectly valid payment on both of them.
You send 1 BTC to an exchange on the legacy chain. Anyone who saw that transaction can rebroadcast the exact same bytes on the enforcing chain, and they are just as valid there. Your second coin moves too — to the same exchange, without you signing anything else. That re-broadcast is the "replay".Forks that planned for this made it impossible. Bitcoin Cash added a fork ID to every signature in 2017, so a transaction signed for one chain is unreadable nonsense on the other. BIP-110 does nothing of the kind — its specification does not mention replay protection at all. The manual defence is to first obtain a coin that exists on only one side and spend it alongside every payment, which makes that payment invalid everywhere else. Otherwise the only thing separating the chains is that their fee markets drift apart, so a fee that gets you relayed on one may be too low on the other.
Sources: BIP-110 specification · SIGHASH_FORKID replay-protection spec
In plain terms
Because a soft fork only removes what is permitted, every block the enforcing side mines is still a completely legal block to an old node — it just looks unusually restrained. That one-way validity decides who can erase whom.
Old nodes automatically follow whichever valid chain has the most accumulated mining work. So if the enforcing chain ever overtakes the legacy chain on total work, old nodes switch to it on their own and every legacy block is undone at once — payments that looked confirmed there simply cease to have happened.The reverse cannot occur: non-signaling blocks are invalid under BIP-110 rules inside the mandatory window, so no amount of legacy mining can pull them back. One side can wipe out the other; the other has no such power. Worth separating two ideas that sound alike: a chain being valid is not the same as it being the chain a node follows. The enforcing branch is valid to old nodes from day one, but they only adopt it if it wins on cumulative work.
Sources: Optech Newsletter #411 (per-branch difficulty & the proof-of-work condition) · Optech: soft fork activation
In plain terms
Bitcoin aims for one block every ten minutes by setting a difficulty target, and it only recalculates that target once every 2,016 blocks. A split does not reset it: both chains wake up with the difficulty that was calibrated for the entire network's mining power.
A chain that keeps only a small share of the miners must still do the full amount of work per block, so its blocks arrive proportionally further apart — ten minutes divided by its share. Keep half the hashrate and blocks take 20 minutes; a tenth, and they take 100 minutes; a hundredth, and you wait more than 16 hours for each one.Relief only arrives after 2,016 of its own blocks — and at a few percent of the hashrate that is more than a year of waiting. Meanwhile transactions keep arriving at the usual rate, so the backlog grows and fees climb. That is the trap: the chain runs slowest precisely when it most needs to show that it works. The table above works this out from the signalling share being measured right now.
Sources: Bitcoin Wiki: Difficulty (2,016-block retarget) · Optech Newsletter #411
Data sources & methodology
Sources (fetched server-side, cached 60s / 10min): mempool.space (legacy chain: blocks, mempool, fees, difficulty), mempool.kilombino.com (Knots-backed instance tracking the enforcing chain), bip110monitor.com (per-period signaling history — data used with attribution), forkmonitor.info (chain tips across node implementations), btcnodes.io (node crawler), mainnet.observer (per-pool signaling, by 0xB10C), Predyx (prediction-market prices), CoinGecko / CoinPaprika (fork-coin spot-listing watch).
Fork-coin price discovery: no major exchange has committed to listing, crediting or pricing a BIP-110 fork coin, so two proxies are tracked. Prediction markets: each row is the last traded YES price on the highest-volume live Predyx market matching that question — deliberately not the "share of open interest", which can differ by tens of points on a thin book. Spot listing: the full CoinGecko coin universe (~18k assets) is scanned every 30 minutes for BIP-110 / Knots / reduced-data names and tickers; on a hit the live BTC ratio and 24h volume are pulled. Bare ticker guesses are not matched — they collide with unrelated listings.
Signaling: a block signals iff its nVersion has BIP9 form (top bits 001) and bit 4 set
— computed independently from raw block versions; the per-period history comes from bip110monitor.com.
Split detection: the two explorers' block hashes are compared at the lower of the two tip heights; on divergence at/after block 961,632 a binary search finds the last common ancestor. Forkmonitor's per-implementation chain tips corroborate which clients follow which tip.
Post-split estimates: while both chains carry the split-inherited difficulty, hashrate share is
estimated from blocks found: share = n_chain / n_total (±1σ = √(p(1−p)/n)); once difficulties diverge the
counts are difficulty-weighted. Absolute hashrate: H = n · D · 2³² / T. Gap p-value: the Poisson survival
probability P = e^(−t/λ) that a healthy chain waits at least this long since its last block —
values near zero suggest a stall or hashrate exit.
Deployment constants (bip-0110.mediawiki): bit 4 · threshold 1,109/2,016 (55%) · mandatory signaling 961,632–963,647 · lock-in ≤ 963,648 · active ≤ 965,664 · expiry +52,416 blocks.
No side, no agenda — this exists to show data, not to change the outcome. This page takes no position on whether BIP-110 should activate, whether a fork should happen, or which chain anyone should follow, run, mine or value. It is not campaigning for or against the proposal or any of the people and projects named on it. Every figure is published with its source, its method and its bias direction precisely so the measurement can be checked and argued with rather than believed — and evidence that cuts against any particular reading is shown alongside the rest, not omitted. Nothing here is an attempt to move signaling, hashrate, node counts, prices or sentiment in any direction. If a number here ever influences the thing it measures, that is a failure of this page, not its purpose.
No predictions, no assurances. Nothing on this page is a forecast, a probability, a projection or an opinion about what will happen to BIP-110, to any chain, to any coin, or to anyone's money. Countdowns, estimates, scenarios, overtake tables, scores and indices are arithmetic performed on observations, and they describe only what has already been measured. Where a figure looks like a probability, it is a modelling output under stated assumptions that are very unlikely to hold exactly.
The data may be wrong. This page depends entirely on third-party sources — block explorers, node crawlers, volunteer trackers, prediction markets and a hand-maintained register. Any of them may be inaccurate, incomplete, stale, offline, deliberately manipulated, or replaced without notice. Node counts in particular are cheap to inflate, miner signaling is free and reversible, and the markets referenced here are extremely thin. Fallback sources engage silently and are named in each panel when they do. No assurance of accuracy, completeness, timeliness or fitness for any purpose is given, and none of it is independently audited.
Not advice, not guidance. This is an informational and educational research tool published as-is. It is not financial, investment, trading, accounting, legal or tax advice, not a recommendation or solicitation to buy, sell, hold, mine, fork, upgrade, run any software or take any other action, and not guidance on how to handle a chain split or any assets. Do your own research and consult qualified professionals. Any decision you take is yours alone. Use at your own risk.