When we find that Mining Scan published something wrong, we fix it — and we record it here. This is the companion to our live data status: that page says how trustworthy the data is right now, this one owns the times it wasn’t.
What was wrong: The pool tables carried a column headed 'Blk/100', which reads as this pool's share of the last 100 blocks. The number under it was something else entirely: the pool's lifetime block count, passed through the API under the name blocks_last_100. On live data that produced readings like 4,287,949 for a single pool on one coin — a figure that is impossible to interpret as a share of 100 blocks, and which no visitor could reconcile with anything else on the page.
What we did: The field is now called what it is — blocks_found — and the column is headed 'Blocks', with a note that it counts every block this pool has found for this coin, all time. No number changed; only the label, which was the part that was false.
Who it affected: Anyone comparing pools by that column was comparing lifetime totals while believing they were comparing recent share, which favours old pools over currently productive ones.
What was wrong: A block has exactly one finder, yet 582 of the 8,294 block heights we recorded over 30 days (7%) were claimed by two or more pools for the same coin — in the worst case 28 different pools all credited with the same Bitcoin block. The cause: several pools display 'last block: N' meaning the network's newest block, not one they found, and we read it as a discovery by that pool. Checked against the live chain, the claimed Bitcoin heights sat just below the real chain tip, which confirms it.
What we did: A block claimed by more than one pool is now credited to nobody rather than to everybody — we do not know which pool found it, so we no longer imply that we do. Such blocks are excluded from the recent-blocks feed and from each pool's block count and last-block time. The raw claims remain inspectable via ?include_contested=true, marked with how many pools claimed them, and the share of contested blocks is now a tracked number on our own health check.
Who it affected: Pool pages and the block feed could show a block a pool did not find; affected pools' last-block times looked more recent than they were.
What was wrong: The check meant to catch a source serving a stale, unchanging payload reported 26-34% of pairs as frozen. Almost all of that was false: 937 of ~960 flagged pairs were simply idle pools reporting 0 hashrate and 0 miners (an honest 'nobody is mining here' state), and most of the rest were the MiningPoolStats aggregator, which we poll only every 4 hours — so identical values between samples are expected, not a freeze. Genuine frozen data among the pools we scan densely was about 1.6%.
What we did: The frozen check now judges only actively-mining pools (non-zero hashrate or miners) from sources we sample frequently, so 'frozen' means what it says: a live pool whose numbers stopped moving. Idle pools are treated as idle, not broken.
Who it affected: Our own alerting cried wolf at 26-34% when the real figure was near 1-2%; no visitor-facing number was wrong, but the noise could have buried a real freeze.
What was wrong: The homepage showed 912 pools and 447 coins as single figures. But 91 of those pools had never returned any data (discovered but silent), and 153 of the listed coins had no pool mining them. Counting idle shells alongside live sources overstated how much of the directory was actually reporting.
What we did: The big number now shows what is live right now (821 pools, 447 coins with pools), with the full breadth shown beside it as a plain breakdown — found / idle for pools, listed / live for coins. A pool nobody mines is labelled idle, not folded into the headline.
Who it affected: Visitors reading the headline counts saw a larger 'active' figure than was truly live.
What was wrong: When the status page first launched it summed two overlapping groups of pools (those with block detail and those with none) and reported 850, which is more than the 821 pools actually seen in 48 hours. A pool that reports only an aggregate 24h count fell into both groups and was counted twice.
What we did: Replaced the overlapping sum with a clean three-way split — per-block detail, aggregate-only, and no block data — that adds up to exactly the number of pools seen, and stated plainly why that differs from the full catalogue size.
Who it affected: For a short time the status page's own coverage figure was inflated by 29 pools.
What was wrong: Between 9 and 23 July the block-collection channel silently stopped working (our third-party page-rendering account was blocked). No new blocks were recorded for nearly two weeks, so block figures on the site were frozen in the past while still appearing current.
What we did: Replaced the third-party dependency with our own page rendering, restarted collection, and added a monitor that now alerts us the same hour if the intake channel ever fails again — instead of us discovering it days later.
Who it affected: For about 13 days, block-related figures did not advance and were older than they looked.
What was wrong: The internal health score stayed at 100/100 during the 13-day block-stream stall, because it only checked whether new rows were being written — not whether the data was actually progressing. Writing a row is not the same as the data moving forward.
What we did: Rewrote the health score to prove progress, not just writes: a dead block stream and frozen (unchanging) data now visibly lower the score. The very same score is published on the public status page, so there is no separate, prettier number for visitors.
Who it affected: The problem was real but invisible to our own alerting for the duration of the stall.
What was wrong: Several Kaspa (KAS) pools displayed a figure around 466,000,000 under blocks found. That number was the Kaspa network's block height, not blocks those pools found, and the underlying rows were about a month old but shown under a 'live' badge.
What we did: Published metrics are now bound to a 48-hour freshness window: a stale value is never shown as live. Those pools now correctly show no block count rather than a wrong one — where a pool publishes nothing for a field, we leave it blank instead of inventing a value.
Who it affected: Anyone reading block counts for those KAS pools saw a wildly inflated, month-old figure.
Live interactive directory: mining-scan.com