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 Pooltag 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 address0xCe7864A8...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!