Following up on my earlier thread about recovering pre-2015 Bitcoin stale blocks from merged-mined chains (here), I kept pulling on that line of work and have created a new tool in service of the Bitcoin monitoring mission: the Merge Mining Monitor.
As in the original post, Stifter et al. showed that merge-mined child chains preserve the Bitcoin parent headers their miners actually hashed. That makes them a side channel into Bitcoin stale and orphan blocks, as well as a way to associate child-chain blocks with the Bitcoin parent headers they committed to.
What began as a historical data recovery exercise turned into a live and historical monitor (I did things a bit backwards compared with the original plan, at least in terms of publishing the datasets etc.). The monitor reads AuxPoW evidence across six live producers, 17 recovered child-chain datasets, and ten catalogued chains where data is still missing. It then makes the resulting pool attribution, child-chain attribution, stale-block evidence, and orphan evidence explorable in a fork-observer-like tree view.
The current record is 2,200+ recovered stale & orphan blocks from current chain tip right back to 2011 when Namecoin started merge-mining with Bitcoin. Many of those blocks have no durable trace left on the Bitcoin network itself.
Even though direct Bitcoin-network monitoring is much more mature in 2026, the value of this side channel is still apparent. For example, the monitor recovered an F2Pool stale at Bitcoin height 953,715 via RSK, around two weeks ago at time of writing, which does not appear to have propagated widely on the Bitcoin network: F2Pool 953715 on RSK. There are many such instances, with this just being the most recent.
I have plans to add more visualisations, including graphs of merge-mining breakdown over time (blocks per difficulty period for each chain, child-chain difficulty relative to Bitcoin, and so on), and better ways to show the cadence of block production across chains. Some of the facets I want to explore:
block timestamp differentials, including whether cross-chain timing anomalies point to anything worth investigating;
mining proxy relationships, including cross-checking 0xB10C’s AntPool-and-friends research from another data source;
mining pool dynamics, which was the original stale-block data question that set me down this rabbit hole;
Foundry produced a very high number of stale blocks on 11/12th September 2025 as recorded in the records of RSK and Fractal Bitcoin: Merge Mining Monitor
I’ve not dug into this deeply at this stage, and this certainly warrants a deeper investigation, but the preliminary (AI-assisted) findings are:
20 stale Foundry blocks between heights 914261 and 914373, a window of roughly 20 hours running from 2025-09-11 17:48 UTC to 2025-09-12 14:05 UTC. Every stale block in that window is Foundry’s; no other pool lost a single block.
All 20 are genuine full-difficulty Bitcoin blocks. I re-verified each stored 80-byte header independently of the monitor’s classifier: the header hashes to its claimed block hash, the hash meets the header’s own nBits target, the nBits matches the canonical difficulty epoch at that height, and the prev hash points at the canonical parent.
These blocks appear never to have reached the Bitcoin network. There are no ForkMonitor/fork.observer/stale-blocks stale-candidate entries near these heights, and I found no discussion of the event anywhere online. The only surviving evidence is the AuxPoW commitments captured by RSK and Fractal Bitcoin.
The header timestamps support this. In a normal propagation race the competing blocks are seconds apart. Here, 18 of the 20 losing blocks carry timestamps 135 to 1621 seconds (median ~600s) before the canonical winner at the same height. The network wasn’t racing Foundry, it simply kept mining as though Foundry’s blocks didn’t exist. (The other 2 look like ordinary races: one 0s self-race and one 6s loss to F2Pool.)
Foundry’s canonical share over the window was ~18% (20 of 113 blocks), well below the ~29% it held across the two weeks either side (592 of 2,022 blocks). Counting the stales, the network found 133 full-difficulty solutions in the window (113 canonical + 20 stale) and Foundry found 40 of them (20 + 20), i.e. 30%, right at its normal share. So the pool’s hashrate was fine; roughly half the blocks it found were silently lost. The 20 stales sit at 16 distinct heights (4 heights have two Foundry stales each, and only one block per height can win; at 914261 the winner was Foundry itself), so the incident cost the pool 15 heights it would otherwise almost certainly have won: ~46.9 BTC in foregone subsidy plus fees.
Every stale builds on a canonical parent and none of them chain onto each other, which suggests the found blocks never even made it back into Foundry’s own block templates. That points at a failure in the block-submission path at the pool layer rather than a network partition.
Attribution is high-confidence on two independent bases: 13 of the 20 carry the Foundry USA Pool tag in the Bitcoin parent coinbase embedded in Fractal’s AuxPoW proof, and the remaining 7 (RSK-only evidence) pay out to Foundry’s known RSK reward address 0xCe7864A8...845D4a.
The evidence is publicly and independently checkable. For example, for the selected block above (height 914342): Fractal block 1061372 is canonical on Fractal and commits to the stale parent, and RSK block 0x45b485e9… at height 7987912, whose captured AuxPoW embeds the same parent header, is visible on Blockscout as mined by Foundry’s RSK address (that RSK block was itself reorged out, consistent with its Bitcoin parent never propagating, but Blockscout retains it as an uncle).
One caveat: header timestamps are miner-set, so any single delta could be clock skew. But 18 losses in one direction averaging ~12 minutes, plus zero sightings by Bitcoin network monitors, is hard to read as anything other than ~20 hours of Foundry’s blocks intermittently failing to propagate?
Regardless, an event that cost them dearly (~46.9 BTC), which could have been openly detected had this monitor been operating!
I wonder if that indicates the foundry blocks were invalid somehow – too many transactions, bad transaction ordering, an invalid transaction in a mempool, or bad math in the coinbase somewhere? That would cause block relay to fail very quickly. As an FPPS pool, presumably individual miners didn’t see an impact.
I just had a look through KIT block announcement data shared by @matthias, and none of the block hashes seem to have been announced to their monitoring nodes (which only receive INVs, not compact blocks).
Deadmanoz · 
Anthony Towns · 
b10c ·