On March 29, 2026, Public Pool — one of the most popular solo Bitcoin mining pools — experienced an outage lasting approximately 9.5 hours. During that window, publicly available statistics from CKPool's three solo mining instances recorded a sharp influx of users, workers, and hashrate. This article examines the data.
This article is a data analysis exercise, not a commentary on Public Pool's reliability. Outages happen. Public Pool is a valuable open-source project that serves the solo mining community. The data presented here was interesting enough to write up — nothing more.
The Outage
Public Pool went offline at approximately 04:27 UTC on March 29, 2026. The service recovered at 13:59 UTC. Public Pool posted on X that the outage was caused by "an improperly configured service [that] failed to restart."
When a mining pool goes down, miners with a configured fallback pool will automatically reconnect to their backup. Many solo mining devices — particularly those running AxeOS firmware (Bitaxe, NerdQAxe++, NerdOCTAXE, and others) — ship with solo.ckpool.org as the default fallback pool. This means that when Public Pool went offline, a significant number of miners automatically redirected their hashrate to CKPool.
Data Sources
The data in this analysis was collected from the publicly available statistics pages for CKPool's three solo mining instances:
- solostats.ckpool.org — Primary instance (US)
- eusolostats.ckpool.org — European instance
- ausolostats.ckpool.org — Australian instance
Each site publishes historical data at one-minute granularity covering approximately four days. The data includes user counts (unique wallet addresses), worker counts (individual mining devices), and hashrate at multiple averaging intervals. Public Pool's device table was captured from web.public-pool.io shortly after recovery.
User and Worker Migration
User and worker counts are the clearest indicator of the migration because they reflect connections immediately — unlike hashrate, which requires time to accumulate through a rolling average. The data shows that the migration was nearly instantaneous and then completely flat for the duration of the outage.
The following table shows the minute-level detail of the migration during the first 90 minutes, followed by 30-minute increments through the rest of the outage. T=0 represents the start of the outage at 04:27 UTC.
| T | UTC Time | Users | Δ Users | Workers | Δ Workers |
|---|---|---|---|---|---|
| −30 min | 03:57 | 31,078 | — | 52,439 | — |
| −5 min | 04:22 | 31,099 | — | 52,448 | — |
| 0 min | 04:27 | 32,766 | +1,702 | 54,863 | +2,417 |
| +3 min | 04:30 | 35,255 | +4,191 | 58,496 | +6,050 |
| +5 min | 04:32 | 37,039 | +5,975 | 61,087 | +8,641 |
| +8 min | 04:35 | 39,897 | +8,833 | 65,384 | +12,938 |
| +10 min | 04:37 | 40,707 | +9,643 | 66,710 | +14,264 |
| +15 min | 04:42 | 40,945 | +9,881 | 67,161 | +14,715 |
| +20 min | 04:47 | 41,136 | +10,073 | 67,493 | +15,047 |
| +30 min | 04:57 | 41,446 | +10,382 | 67,902 | +15,456 |
| +60 min | 05:27 | 41,544 | +10,480 | 68,089 | +15,643 |
| +90 min | 05:57 | 41,558 | +10,494 | 68,033 | +15,587 |
| +3 hrs | 07:27 | 41,587 | +10,523 | 68,194 | +15,748 |
| +5 hrs | 09:27 | 41,633 | +10,569 | 68,428 | +15,982 |
| +7 hrs | 11:27 | 41,731 | +10,667 | 68,652 | +16,206 |
| +9 hrs | 13:27 | 41,901 | +10,837 | 68,818 | +16,372 |
| +9.5 hrs | 13:57 | 38,388 | +7,324 | 63,494 | +11,048 |
| +10 hrs | 14:27 | 31,819 | +755 | 53,818 | +1,372 |
| +11 hrs | 15:27 | 31,825 | +761 | 53,816 | +1,370 |
Two things are immediately apparent. First, the migration was fast: within 10 minutes of the outage, over 9,600 users and 14,200 workers had already connected to CKPool. By T+30 minutes, the migration was essentially complete at approximately 10,400 users and 15,500 workers. Second, the counts were remarkably flat for the remaining 9 hours of the outage — less than 1% variation — confirming that no significant additional migration occurred after the initial wave.
The recovery was equally sharp. Between T+9 hours and T+10 hours, nearly all migrated miners returned to Public Pool within a single 30-minute window.
Per-Instance Breakdown
The Solo (US) instance absorbed the vast majority of the migrated miners.
| Instance | Δ Users | Δ Workers |
|---|---|---|
| Solo (US) | +10,103 | +15,315 |
| EU | +476 | +643 |
| AU | +39 | +60 |
| Total | +10,618 | +16,018 |
Hashrate Impact
The hashrate data requires more careful interpretation than the user/worker counts. The user and worker data provides a way to distinguish hashrate changes caused by the Public Pool migration from normal CKPool hashrate variance.
The key observation: user and worker counts were flat from T+30 minutes onward, meaning no new miners were arriving after that point. Any hashrate changes after T+30 minutes are therefore attributable to normal CKPool variance — not the Public Pool migration.
| T | UTC Time | Solo (US) | EU | AU | Combined | Δ vs Baseline | Δ Users |
|---|---|---|---|---|---|---|---|
| −30 min | 03:57 | 146.8 | 60.5 | 6.7 | 214.0 | — | — |
| −5 min | 04:22 | 147.0 | 60.3 | 6.7 | 214.0 | — | — |
| 0 min | 04:27 | 150.2 | 60.9 | 6.8 | 217.8 | +3.8 | +1,702 |
| +10 min | 04:37 | 157.0 | 61.0 | 7.0 | 225.0 | +11.0 | +9,643 |
| +20 min | 04:47 | 162.0 | 61.0 | 7.1 | 230.1 | +16.1 | +10,073 |
| +30 min | 04:57 | 164.0 | 60.9 | 7.1 | 232.0 | +18.0 | +10,382 |
| +60 min | 05:27 | 165.7 | 59.5 | 7.0 | 232.2 | +18.2 | +10,480 |
| +90 min | 05:57 | 165.4 | 57.4 | 7.0 | 229.8 | +15.8 | +10,494 |
| +3 hrs | 07:27 | 183.7 | 50.7 | 6.2 | 240.6 | +26.6 | +10,523 |
| +5 hrs | 09:27 | 185.5 | 76.7 | 6.4 | 268.6 | +54.6 | +10,569 |
| +7 hrs | 11:27 | 182.2 | 74.6 | 6.4 | 263.2 | +49.2 | +10,667 |
| +9 hrs | 13:27 | 187.0 | 76.5 | 6.2 | 269.7 | +55.7 | +10,837 |
| +9.5 hrs | 13:57 | 183.7 | 71.0 | 6.9 | 261.7 | +47.7 | +7,324 |
| +10 hrs | 14:27 | 174.1 | 66.3 | 6.2 | 246.5 | +32.5 | +755 |
| +11 hrs | 15:27 | 171.7 | 64.7 | 6.3 | 242.7 | +28.7 | +761 |
The pre-outage baseline was 214.0 PH/s. At T+30 minutes — the point at which user and worker counts had stabilized — the combined hashrate was 232.0 PH/s, an increase of ~18 PH/s. At T+60 minutes, it was 232.2 PH/s, confirming the same figure. This ~18 PH/s represents the hashrate that arrived with the migrated Public Pool miners.
After T+60 minutes, the hashrate continued to climb — reaching as high as 271 PH/s at T+4.5 hours — but the user and worker counts remained flat throughout. This additional ~39 PH/s of variance occurred with no corresponding increase in connected miners and is therefore attributable to normal CKPool hashrate fluctuation, not the Public Pool migration.
Public Pool's Device Composition
Public Pool's web interface displays a breakdown of currently connected devices by type. The following table was captured shortly after recovery and represents the pool's active device population.
| Device | Workers | Total Hashrate | Default CKPool Fallback? |
|---|---|---|---|
| Bitaxe | 17,055 | 18.7 PH/s | Yes (AxeOS default) |
| NerdQAxe++ | 2,052 | 10.4 PH/s | Yes (AxeOS default) |
| cgminer | 862 | 8.3 PH/s | Likely (advanced users) |
| Antminer | 214 | 2.9 PH/s | Likely (ASIC miners) |
| NerdOCTAXE | 187 | 2.0 PH/s | Yes (AxeOS default) |
| LuckyMiner | 2,833 | 881.5 TH/s | Varies |
| NerdQAxe+ | 307 | 768.1 TH/s | Yes (AxeOS default) |
| NerdAxe | 497 | 408.3 TH/s | Yes (AxeOS default) |
| Others | 355 | ~1.7 PH/s | Varies |
| Visible Total | 24,362 | ~46 PH/s |
At the time of data collection, Public Pool's API reported 142,492 total miners. The difference between the 24,362 visible workers in the table and the 142,492 total is largely composed of NerdMiner and similar ultra-low-hashrate devices that contribute negligible hashrate and do not appear in the device summary table.
Matching the Numbers
CKPool gained approximately 15,500 workers during the outage. Public Pool's device table shows approximately 24,400 workers across all visible device types. This means roughly 64% of Public Pool's visible workers had CKPool configured as a fallback and successfully failed over.
On the hashrate side, the ~18 PH/s increase observed at CKPool represents approximately 40% of Public Pool's ~45 PH/s pre-outage hashrate. This means the remaining ~27 PH/s — carried by the ~8,800 visible workers that did not appear on CKPool — either failed over to a different pool, had no fallback configured, or were otherwise unable to reconnect.
Summary of the migration:
- ~10,400 unique wallet addresses appeared on CKPool during the outage
- ~15,500 additional mining devices connected to CKPool
- ~18 PH/s hashrate increase attributable to the migration (measured at T+30 min when user/worker counts had stabilized)
- Migration completed within approximately 30 minutes of the outage
- Return to Public Pool completed within approximately 30 minutes of recovery
Observations
Several things stand out from this data:
Fallback pools work — and they work fast. Within 10 minutes of the outage, over 14,000 workers had already reconnected to CKPool. By 30 minutes, the migration was complete. The return to Public Pool after recovery was equally rapid. This demonstrates that stratum failover, as implemented in AxeOS and similar firmware, functions reliably and quickly.
User/worker counts are a better migration indicator than hashrate. The 5-minute hashrate average continued to climb for hours after the migration was complete, reaching values that might suggest a much larger migration than actually occurred. The flat user/worker counts during the same period confirm that no additional miners were arriving — the hashrate variance was from CKPool's existing user base. When analyzing pool migration events, user and worker counts provide a more accurate and immediate signal than hashrate.
About 64% of Public Pool's visible workers failed over to CKPool. The remaining 36% either had a different fallback pool configured, had no fallback at all, or were unable to reconnect. The ~118,000 invisible miners (mostly NerdMiners and similar devices) largely did not appear on CKPool — these devices contribute negligible hashrate and many may not have fallback pools configured.
About 40% of Public Pool's hashrate reached CKPool. The ~18 PH/s that arrived at CKPool accounts for roughly 40% of Public Pool's ~45 PH/s. The remaining ~27 PH/s was carried by miners that did not fail over to CKPool — likely a mix of miners with different fallback pools and miners with no fallback configured.
Geographic distribution is notable. Public Pool operates a single server located in the United States. During the outage, CKPool's EU instance gained approximately 476 users and 643 workers, and the AU instance gained approximately 39 users and 60 workers. While these numbers are small compared to the US instance, they confirm that a meaningful number of miners in Europe and Oceania are using a US-based pool as their primary — accepting the latency tradeoff for Public Pool's zero-fee, open-source model. These miners' default fallback to CKPool's regional instances (EU and AU) provided them with lower-latency connections during the outage than they had to their primary pool under normal operation.
The 1.5 workers-per-user ratio is informative. The migrated population averaged approximately 1.5 workers per unique wallet address. This suggests the typical Public Pool user who has a properly configured fallback is running between one and two mining devices — consistent with the hobbyist solo mining demographic that characterizes both Public Pool and CKPool's user base.
Hashrate concentration is significant. Public Pool's 142,492 total miners produce approximately 46 PH/s of hashrate. The top 24,400 visible devices (17% of total miners) account for essentially all of that hashrate. The remaining 83% of miners are ultra-low-hashrate devices. This concentration means that the miners who matter most for hashrate are also the ones most likely to have properly configured fallback pools.
The Default Wallet Address
Bitaxe devices ship with a factory default wallet address (bc1qnp...4rkq). Users are expected to replace this with their own address before mining. The AxeOS firmware has separate configuration fields for the primary pool and the fallback pool, each with its own URL and wallet address.
CKPool's historical data for this address reveals a striking pattern during the outage:
| Period | Workers | Hashrate (5m) |
|---|---|---|
| Pre-outage (03:27–04:20 UTC) | ~100 | ~89 TH/s |
| During outage (05:30–13:30 UTC) | ~1,415 | ~1,258 TH/s |
| Post-recovery (14:30–15:30 UTC) | ~120 | ~107 TH/s |
| Increase during outage | +~1,300 | +~1,170 TH/s |
Public Pool currently shows approximately 480 workers on this same address, producing roughly 517 TH/s. Since the outage only affected Public Pool, we would expect the increase observed on CKPool to approximately match Public Pool's worker count and hashrate for this address. Instead, the observed increase was roughly 2.5 times larger.
The likely explanation: many users changed their primary pool wallet address to their own but left the fallback pool wallet address at the factory default. On Public Pool, these miners appear under their own address. When they failed over to CKPool, they connected using the default address from the untouched fallback configuration. The roughly 800-worker difference between the CKPool increase (~1,300) and Public Pool's count (~480) represents miners in this category.
Takeaway for Bitaxe owners:
In addition to the ~480 miners who never changed the default address at all, approximately 800 more miners would lose their block reward during any failover event because their fallback wallet address still points to the Bitaxe project's address rather than their own. If you are mining with a Bitaxe or similar AxeOS device, check both your primary and fallback pool wallet addresses to ensure they are set to your own Bitcoin address.
Acknowledgements
Thank you to mutatrum for reviewing this article and suggesting the examination of the default wallet address.
Questions, corrections, or feedback? Reach out to @Atlaspool_io on X.