The Myth of Multiple Stratum Servers:
Does Mining Closer Really Help?
A data-driven analysis of latency, stale shares, and orphan risk in cryptocurrency mining pools.
For coins with block times of 60 seconds or more, connecting to a geographically closer stratum server provides no meaningful advantage. Latency differences are negligible compared to block time, hashrate is completely unaffected by ping, and the stale share increase from cross-continent mining is less than 0.1%.
Current Network Facts
All numbers in this analysis are based on real C64Chain mainnet data, but the conclusions apply to any CryptoNote or RandomX coin with similar block times.
| Latency Scenario | Round-Trip Time |
|---|---|
| Same region (EU↔EU, Asia↔Asia) | ~20ms |
| Cross-continent (EU↔Asia) | ~200ms |
The 3 Latency-Sensitive Operations
1. Job Delivery — New Block Template
When someone on the network finds a block, the pool must send miners a new job so they stop mining the old (now stale) block. This is one of the main causes of stale and rejected shares.
→ P2P propagation to daemon (~1-5s)
→ Stratum polls daemon (up to 1s interval)
→ Stratum sends job to miner (network latency)
| Setup | Daemon Poll RTT | Worst-Case Stale Window |
|---|---|---|
| Local daemon + local stratum | ~1ms | ~1.0s |
| Remote daemon (EU) + local stratum | ~200ms | ~1.2s |
Extra stale work: ~200ms. Relative to 300s block time: 200ms / 300,000ms = 0.067% of hashrate wasted.
Imagine you're in a 5-hour exam and you lose 0.36 seconds because the clock on your wall is slightly behind the official one. That's the scale of this "disadvantage."
2. Share Submission — The Normal Case (99.999% of Shares)
Miner finds a share → sends to stratum → stratum validates locally → records in database.
| Setup | Hash Validation | Database Write | Miner Waits? |
|---|---|---|---|
| Everything local | <1ms | <1ms | No |
| Remote database (WAN) | <1ms (local RandomX!) | ~200ms | No |
The miner does NOT wait for the database write. The stratum validates the hash locally with RandomX, sends "accepted" back to the miner immediately, then writes to the database asynchronously. The miner keeps hashing at full speed the entire time.
When you drop a letter in a mailbox, you don't stand there waiting for it to arrive at its destination. You walk away and keep doing your thing. Same here — the miner drops the share and keeps hashing.
3. Block Solution Submission — The Critical Path (But Rare)
This is the only operation where latency could theoretically cost real money. When a share meets network difficulty, the stratum must submit it to the daemon as fast as possible.
→ Stratum validates hash (local RandomX, <1ms)
→ Stratum calls submit_block on daemon
→ LOCAL daemon: <1ms RTT
→ REMOTE daemon: ~200ms RTT
→ Daemon validates + propagates via P2P
Does 200ms Extra Delay Actually Cause Orphans?
An orphan happens when two miners find valid blocks at nearly the same time and only one survives. Let's calculate the probability using real network data:
// Real C64Chain network values
Network hashrate: 1,000,000 H/s
Network difficulty: 300,000,000
Block rate (λ): 1,000,000 / 300,000,000 = 0.00333 blocks/sec
P(competing block within 200ms) = 1 - e(-0.00333 × 0.2)
= 1 - e(-0.000667)
≈ 0.000667
= 0.067%Imagine you're fishing in a massive lake with one other person. The chance that you both catch a fish within the same 0.2 seconds is essentially zero. That's how unlikely a block race is on a 5-minute block time coin.
Local Daemon vs. Remote Daemon
| Aspect | Local Daemon | Remote Daemon (WAN) |
|---|---|---|
| Job template latency | <1ms | ~200ms |
| Block submission latency | <1ms | ~200ms |
| Stale share rate | ~0.33% | ~0.40% |
| Orphan risk increase | Baseline | +0.067% |
| Disk space required | Full blockchain | None |
| Bandwidth | P2P sync traffic | Only RPC calls |
| Maintenance | Must keep synced | Zero |
| Failure mode | Survives WAN outage | Dead on WAN outage |
A local daemon isn't about speed — it's about resilience. If the WAN link drops for 30 seconds, a local daemon keeps the stratum running. Without one, any internet hiccup between continents kills the entire operation for those miners.
A local daemon is like having a backup generator at home. The lights stay on even if the main power line goes down briefly. Without it, every internet blip kills the whole pool for those miners.
Does the Miner Benefit from 20ms vs 300ms Ping?
The core question: does a miner in Asia benefit from connecting to an Asia stratum server (20ms ping) vs. the EU server (300ms ping)?
Hashrate Impact: Zero
Latency does not reduce hashrate. Period.
The mining loop runs continuously. Whether the "accepted" response comes back in 20ms or 300ms, the miner keeps hashing at full speed. There is no pause, no waiting, no round-trip dependency.
while (true) {
nonce++
hash = RandomX(blob, nonce)
if (hash < share_target) {
send_share(nonce) // non-blocking, fire-and-forget
}
// immediately continues — does NOT wait for "accepted"
}Stale Share Impact: Negligible
When a new block appears, the job reaches the miner 280ms later with a 300ms connection vs. 20ms. During those 280ms, the miner hashes the old (stale) block.
Extra stale time: 280ms
Block time: 300,000ms
Stale rate increase: 280 / 300,000 = 0.093%A miner at 10 KH/s produces about 2.8 extra stale hashes per block transition. With 288 blocks/day, that's ~806 wasted hashes out of 864,000,000 total hashes/day.
Block Finding Delay
If the miner finds a block, the solution travels through the system with additional one-way latency:
| Miner Setup | Miner → Stratum | Stratum → Daemon | Total Delay |
|---|---|---|---|
| 20ms ping + local daemon | 10ms | 1ms | 11ms |
| 20ms ping + remote daemon | 10ms | 100ms | 110ms |
| 300ms ping + local daemon | 150ms | 1ms | 151ms |
| 300ms ping + remote daemon | 150ms | 100ms | 250ms |
Worst case difference: 239ms. Orphan probability from that extra delay: still just ~0.067%.
Think of mining like a lottery where you continuously scratch tickets. Whether the shop is 1 minute or 5 minutes from the lottery office doesn't matter — you keep scratching at the same speed regardless. The only tiny disadvantage is that when the winning numbers change, you find out a few seconds later and might scratch one extra old ticket. But you scratch millions of tickets per day, so that one wasted ticket is meaningless.
When Does Latency Actually Matter?
| Block Time | Example | Stale Impact (300ms) | Orphan Risk | Latency Matters? |
|---|---|---|---|---|
| 1 second | Solana | 30% | Very high | YES — critical |
| 10 seconds | — | 3% | High | Yes — significant |
| 15 seconds | old Ethereum | 2% | Moderate | Noticeable |
| 60 seconds | — | 0.5% | Low | Barely |
| 300 seconds | C64Chain | 0.1% | Negligible | No |
| 600 seconds | Monero | 0.05% | Negligible | No |
The rule of thumb: latency matters when it's a significant fraction of the block time. For more context on block times and how they relate to mining, see our getting started guide. For C64Chain with 5-minute blocks, even intercontinental latency is a rounding error.
Bottom Line
| Factor | Impact of Remote Stratum | Worth Optimizing? |
|---|---|---|
| Hashrate | Zero difference | No |
| Stale shares | +0.07–0.09% | No |
| Orphan risk | 1 in 3,000 blocks | Only if coin is very valuable |
| WAN resilience | Stratum dies on outage | Yes — the real reason |
For miners: Connect to whichever stratum server you want. Your hashrate and earnings will be identical whether you're 20ms or 300ms away. The differences are smaller than normal pool luck variance.
For pool operators: The only legitimate reason to run regional stratum servers is uptime resilience against WAN outages — not speed. If your intercontinental link is stable, a single stratum location is perfectly fine for block times of 60 seconds or more.
The myth debunked: "Closer stratum = more coins" is false for any coin with a block time over 30 seconds. The math doesn't lie — 200ms of latency on a 300-second block time is a 0.067% difference, completely dwarfed by normal mining luck variance of 10–50%.