Every Millisecond Counts: How AtlasPool Leads in Block Notification Speed

After a three-week tuning effort on our Ashburn, Virginia endpoint, AtlasPool is among the fastest solo mining pools for block notifications. Here's what the data shows:

• Faster than other solo pools. Across 499 blocks on stratum.work, AtlasPool won a plurality of notification races against all observed solo pools.
• Fastest complete templates (with transaction fees). When compared against all pools (including large hashrate pools like F2Pool and MARA), AtlasPool delivered the first complete block template more often than any other individual pool.
• Faster than a local node. In independent testing, AtlasPool beat a local Umbrel Home node 84% of the time despite being 1000+ km away.

Why Block Notification Speed Matters

When a new block is found on the Bitcoin network, every miner still working on the old block is wasting energy. Until your pool notifies you and delivers a fresh template, every hash is wasted. A 1-second notification delay means 1/600th of the block interval (0.17%) is spent on stale work. At 144 blocks per day, that's 144 seconds per day per miner hashing against a block that's already been found.

Scale that across a pool and the effect becomes easier to see. If 50,000 miners are connected and each receives a usable template 1 second later, that is 50,000 miner-seconds per block spent working on stale information. Over a full year of blocks, that would add up to more than 2.6 billion miner-seconds, or roughly 83 miner-years of cumulative work. No single miner loses 83 years, of course, but the aggregate shows why even small per-block delays can matter at pool scale.

The Results

Across 499 recent blocks (955507 to 956006), we measured via stratum.work, a real-time visualization tool by boerst that monitors mining work notifications from Stratum pools, which solo pool notified connected miners first:

AtlasPool, CKPool EU, and Parasite Pool form a clear top tier, together winning 96% of all notification races. AtlasPool wins the plurality, and when it doesn't win, it's typically within 46ms of the leader.

stratum.work timing chart for block 955756, showing AtlasPool arriving among the first to notify.

A note on empty vs. full block templates

When looking at stratum.work data, it's important to understand that not all block notifications are equal. Many larger pools (particularly those with significant hashrate) send an empty block template the moment a new block is detected on the network. This empty template contains only the coinbase transaction, with no user transactions and no fee revenue beyond the block subsidy. It is a valid template that miners can work on (and empty blocks have been mined throughout Bitcoin's history), but for solo miners the fee revenue matters. The pool sends this empty template to stop miners working on the old block as quickly as possible, even before the new block has been fully validated.

After validating the block and building a proper template with transactions, the pool sends a second notification with the complete block template. This is the template that matters most for solo miners, because it contains the transactions (and fees) that make up the full block reward.

Virtually all solo pools do the right thing: they fully validate the incoming block, build a complete template, and only then notify miners. There is no empty-template shortcut. This means the "first complete template" race is the meaningful comparison for solo miners.

Across blocks 955516 to 955765 (250 blocks), here is which pool delivered the first complete block template:

When measured against all monitored pools (including the large hashrate pools that use the empty-template trick), AtlasPool wins 22% of complete-template races, the highest win rate of any single pool in the comparison, including F2Pool and MARA, which operate with significantly larger infrastructure budgets.

How Block Notifications Work

To understand where speed comes from, here's the pipeline from "someone finds a block" to "your miner starts working on the next one":

Block discovery (Steps 1-2): The pool's Bitcoin node learns about a new block from its peers. In the best case, a peer pushes a compact block (BIP 152) that the node reconstructs using transactions already in its mempool. The speed here depends entirely on peer quality and mempool completeness. A node with well-connected peers and a full mempool reconstructs blocks instantly. A poorly connected node may need extra round-trips to fetch missing transactions.

Validation (Steps 3-4): The node validates every transaction in the block (signatures, UTXOs, consensus rules) and signals the stratum server via ZMQ. This is CPU-intensive work where hardware with SHA-256 acceleration has an advantage.

Template delivery (Steps 5-8): The stratum server requests a new block template from the node, builds a mining.notify payload (coinbase transaction parts, merkle branches, previous block hash), and pushes it to every connected miner. Miners construct their own candidate block headers from these components and begin hashing against the new template.

The total time from "block exists on the network" to "all miners notified" is typically 100 to 500ms for a well-tuned setup. A poorly tuned setup can take 1-3 seconds or more.

What We Did: The IAD Tuning Sprint

Over three weeks in June 2026, we focused on our Ashburn, Virginia endpoint with one goal: minimize the time from block appearance on the network to miner notification.

Hardware

We deploy on Amazon EC2 instances powered by AWS Graviton processors. These are ARM-based chips designed for high throughput. We compiled our Bitcoin node to take full advantage of Graviton's SHA-256 hardware acceleration instructions, ensuring block validation runs as fast as the silicon allows. During this process, Philip D'Auth discovered a bug in how the node's build system detects and enables ARM SHA-256 acceleration, and submitted a fix upstream (Knots PR #309). AtlasPool tested the fix and provided supporting feedback.

Software

We compiled ckpool (AtlasPool's stratum server) from the latest source to incorporate recent performance improvements. We tuned the node's configuration (memory allocation, connection limits, and mempool policies) for the specific workload of a mining pool node.

Peering

This is where the biggest gains came from. A node is only as fast as its fastest peer. We spent significant effort identifying and connecting to peers most likely to deliver new blocks first, monitoring delivery performance across hundreds of blocks, removing underperforming connections, and adding proven fast sources. The result is a node that consistently hears about new blocks within milliseconds of their appearance on the network.

We plan to apply these same optimizations to all nine AtlasPool endpoints in the coming weeks.

Independent Measurement: str_race

str_race is an open-source tool by ProofOfMike that connects to multiple pools from your own network and measures which pool delivers a new block notification (prevhash change) first. It timestamps arrivals with sub-millisecond precision and reports statistics over a configurable duration.

To validate these results independently, we turned to str_race. Here's a run by ProofOfMike from northeast USA, covering blocks 955765 through 955819 (55 confirmed races):

AtlasPool won 51% of all races outright. When it didn't win, its median delay behind the winner was just 183.6ms. The top three pools (AtlasPool, CKPool EU, Parasite Pool) won all 55 races between them. No other pool won a single one.

Faster Than Your Local Node?

Many solo miners assume that running their own local node is the fastest option. After all, it's on the same network as their miners with negligible latency to the pool. We wanted to test that assumption.

ProofOfMike raised the idea of including local nodes in the test series. The thesis was simple: a small home node running on commodity hardware with mostly default settings may not notify miners about new blocks faster than a properly tuned and highly performant pool node. To test this, we asked X user Huskuldar to run str_race from their home network in the southeastern United States. They configured it to measure block notification timing from:

• AtlasPool (remote, ~1000 km away in Virginia)
• CKPool US (remote)
• Public Pool (remote)
• Their own Umbrel Home (Intel N150 quad-core, 3.6GHz) running Public Pool's stratum (local)
• Their own Umbrel Home running Go Brrr stratum (local)

Over a 12-hour test spanning blocks 955752 through 955819 (68 blocks total):

How is this possible? The local node has negligible network latency to the miners, but it faces disadvantages at earlier steps in the pipeline. We believe the primary factor is peering and proximity to mainnet: a home node connects to whatever peers it discovers through the P2P network's default peer selection, while AtlasPool's node is carefully connected to high-performance peers that deliver new blocks as fast as possible. A well-connected node in a major data center hears about new blocks sooner than a home node with default peer connections, and that head start at Step 1 propagates through the entire pipeline.

Additional factors likely contribute (faster hardware for block validation, tuned mempool for compact block reconstruction), but we haven't isolated their individual impact. What the data shows clearly is the end result: the ~285-385ms that Huskuldar's local node loses to AtlasPool far exceeds the 0-5ms of local network latency it saves by being on the same LAN as the miners.

This doesn't mean local nodes are bad. They serve vital roles in sovereignty, verification, and learning how Bitcoin actually works under the hood. Running your own node and connecting a well-tuned pool are not mutually exclusive choices. Many miners do both.

But not every miner wants to become a node operator or tune peering by hand. For those who want a turnkey solution, a tested solo pool endpoint removes a lot of the operational burden while still delivering strong performance.

If your goal is mining-template speed specifically, this data shows why tuning matters. A well-peered pool endpoint can outpace a default or lightly tuned home node, even when that node is local to the miner. This also does not mean every remote pool will beat every local node. Huskuldar's Umbrel Home is representative of the hardware many home miners run, but results will differ based on your node's hardware, peering configuration, internet connectivity, and geographic location. The best way to know is to test it yourself.

Don't Trust, Verify

git clone https://github.com/proofofmike/stratum-race.git
cd stratum-race
python3 str_race.py

What's Next

The IAD endpoint is our proof of concept. Over the coming weeks, we're applying the same tuning methodology to all nine AtlasPool endpoints worldwide:

• 🇺🇸 Ashburn, VA (US) ✅ Tuned
• 🇺🇸 Portland, OR (US)
• 🇧🇷 São Paulo (BR)
• 🇩🇪 Frankfurt (DE)
• 🇬🇧 London (UK)
• 🇭🇰 Hong Kong (HK)
• 🇮🇳 Mumbai (IN)
• 🇦🇺 Sydney (AU)
• 🇿🇦 Cape Town (ZA)

With nine endpoints across six continents, all reachable via a single anycast hostname, miners worldwide automatically connect to the closest endpoint. Our goal: no matter where you mine, AtlasPool should be among the fastest options available.

Acknowledgments

Several people contributed to this effort:

ProofOfMike - Created str_race, the open-source measurement tool that makes independent, objective comparison possible. ProofOfMike was a sounding board for various testing scenarios and had the idea for including local nodes in tests.

Philip D'Auth - Actively collaborated on tuning strategies, discovered a bug in how Bitcoin Knots compiles on ARM-based hosts and proposed the upstream fix (PR #309), and provided weeks of ideas, testing, and encouragement. Philip is a true friend of AtlasPool.

Huskuldar - Volunteered to run independent tests from their home network, providing the compelling local-node comparison data that shows real-world performance differences between AtlasPool and their own Umbrel local node.

Con Kolivas - Author of ckpool, the stratum server implementation that powers AtlasPool. Con's work is the foundation everything else is built on. Thank you, Con!