Definition
Stale share is a proof of work that your miner computed correctly but submitted too late: by the time the pool received it, the network had already moved on — a new block was found and the pool issued fresh work — so the share no longer applies to the job the pool is tracking. The work was real and the hash was valid, but it answers yesterday's question, so the pool discards it and pays nothing for it. Stale shares are fundamentally a latency problem, not a hardware fault, and a small stale percentage is normal and unavoidable at every scale, from a single Bitaxe to an industrial farm.
Why stale shares happen
Most stale shares cluster in the moments immediately after a block is found somewhere on the network. In Stratum, the pool pushes new work via a mining.notify message; when its clean_jobs flag is set to true, the miner must immediately discard all pending work, because every share against the old job is now worthless. Until that notification crosses the wire and the firmware acts on it, your ASICs are hashing against a dead job — and anything they find in that window arrives stale. Pools typically reject these with a "job not found" style error referencing the outdated job ID. Network round-trip time, pool server distance, packet loss, and slow job handling in firmware all widen the window. On pools that retarget share difficulty on the fly, brief stale spikes can also appear during a difficulty transition, when shares computed against the old target land after the new one takes effect.
Keeping the rate low
The levers are all latency levers. Mine on a geographically close pool endpoint — intercontinental round trips add tens to hundreds of milliseconds to every job change. Use a stable, wired, low-latency connection; Wi-Fi jitter and bufferbloat show up directly in stale counts. Run firmware that processes new-job notifications promptly, since a busy or underpowered control board can sit on a notification while its chips keep grinding the old job. Protocol design matters too: Stratum V2 distributes new jobs more efficiently than Stratum V1's text-based JSON, shrinking the vulnerable window — and can even push a new job's header fields before the full template, so miners restart on fresh work sooner.
Reading your stale rate
Treat the stale percentage as a network health gauge. Well under 1% is typical for a wired connection to a nearby pool; a persistently higher figure usually points to a flaky link, a distant server, a VPN detour, or an overloaded control board — almost never to the hash chips themselves, which have no concept of time or jobs. Compare across pools before blaming your miner: if the stale rate follows the pool, the problem is the path. Stale shares are counted within your overall reject rate, alongside genuinely invalid submissions, so check which category dominates before troubleshooting.
Stale share versus orphan block
Do not confuse the two. A stale share is pool-level bookkeeping: a tiny unit of work that missed its job's lifetime, costing you a share's worth of expected reward. An orphan block is a fully mined block that lost a propagation race at the same height — the network-scale version of arriving late. Same underlying physics, wildly different stakes; both are reminders that in Bitcoin, latency is money.
In Simple Terms
Stale share is a proof of work that your miner computed correctly but submitted too late: by the time the pool received it, the network…