Does stratum latency matter for solo mining?
The honest answer first
Latency does not change your odds of solving a block. Those odds depend only on your hashrate versus the whole network, and they are identical on every pool no matter where its server sits. Anyone who tells you a closer pool gives you a better chance at a block is wrong. What latency does affect is wasted work — and for a busy miner that is a small but real efficiency, not a lottery edge.
Where the milliseconds actually go
When a new block is found anywhere on the network, your pool has to push you fresh work built on that new tip. Until that new-work message reaches you, your miner keeps hashing on the old block — and any share it submits for the old block is stale and thrown away. The farther the pool, the longer that window, and the more shares are wasted at every block change (roughly every ten minutes). A close pool also means faster share submission and fewer dropped connections for devices that reconnect a lot.
Measured latency from Indonesia
TCP round-trip to each pool's stratum endpoint, measured from a home connection in Indonesia (a real SEA miner's vantage point). Your numbers will vary by ISP and country — from Singapore or Malaysia, ckpool's Singapore node may be the closest hop. Table: best-of-5 TCP connects, June 2026; re-run the script below from your own line:
| Pool / endpoint | RTT from Indonesia |
|---|---|
| SoloLuck · Jakarta | ~6 ms |
| solo.ckpool.org · Singapore node | ~17 ms |
| solo.ckpool.org · Australia node | ~123 ms |
| Public Pool · US | ~250 ms |
| solo.ckpool.org · US / EU nodes | ~260 ms |
Against a US-only solo pool the gap is decisive (~40× lower); against a Southeast Asia node like ckpool-Singapore or an anycast pool it is modest. We'd rather you see the real numbers than a marketing claim.
Test it yourself
Don't take our word for it. From a terminal, time the TCP handshake to any pool's stratum port. It warms DNS first, then keeps the fastest of five connects — so you measure the network hop, not a one-off DNS lookup or blip:
python3 -c "
import socket, time
host, port = 'stratum.sololuck.io', 3333
socket.getaddrinfo(host, port) # warm DNS first
best = float('inf')
for _ in range(5):
start = time.perf_counter()
socket.create_connection((host, port), 5).close()
best = min(best, (time.perf_counter() - start) * 1000)
print(round(best, 1), 'ms (best of 5)')
"Swap in any other pool's stratum host and compare the numbers. That TCP round-trip is the network hop — exactly what stale-share waste tracks.
So when does it matter?
- A big ASIC (S19/S21) submitting many shares per second — more shares means more stale ones near a block change, so a regional node saves measurably more work.
- Low-power devices that reconnect often (some Bitaxe/nerdminer firmware) — a short hop means faster reconnects and fewer missed shares.
- It barely matters for a single hobby Bitaxe on a stable line — pick on fee, tiers and trust instead. See /compare.
Ready to start solo mining?
Paste your address and copy the config from /setup, watch the pool on /status, and check every claim on /verify. Mine to your own address — that is what makes it truly solo.
Start MiningCalculate Your Odds
Not ready to point a miner yet? Join Telegram for block & record alerts — no rig required.
FAQ
Does a lower-latency pool give me a better chance of finding a block?
No. Block odds depend only on your hashrate versus the whole network and are identical on every pool. Latency only reduces wasted (stale) shares at block changes - an efficiency, not a probability edge.
How much hashrate do I lose to a far-away pool?
For a small Bitaxe, a negligible amount. For a high-share-rate ASIC, a far pool wastes more shares each time a new block appears because you keep hashing the old block until fresh work arrives. A regional node shortens that window.
What's the lowest-latency solo pool for Southeast Asia?
From Indonesia, SoloLuck's Jakarta node measured ~6 ms versus ~17 ms to a Singapore ckpool node and ~250 ms to US solo pools. You can verify with a TCP-connect timing test from your own connection.