What Is a Stale Share in Bitcoin Mining

A pool dashboard shows three share counters for every miner: accepted, rejected, and stale. The accepted column is the one that earns money. The rejected and stale columns indicate work the pool refused to credit, and persistent counts in either column mean something is off. So what is a stale share in mining, and how does a miner keep the count low? This guide walks through what a stale share actually is, the four main reasons shares go stale, what stale shares cost in lost revenue, and what diagnostic steps to take when the rate climbs above the typical floor of well under 1%.

The short answer: a share that arrived after the pool moved to a new block template

A stale share is a valid share that arrives at the pool too late to count. The miner did real work — computed a hash that satisfied the share target — but by the time the share reached the pool over Stratum, the pool had already moved to a new block template, usually because another miner somewhere on the network found the block first. The pool discards the share because it was built against an outdated template.

Stale shares are distinct from rejected shares. A rejected share is invalid — the hash does not actually satisfy the share target, often due to a hardware error or a corrupted submission. A stale share is valid; it just no longer matters. Both cost the miner uncounted work, but the diagnostic paths differ. The deeper explainer on what shares are in the first place is in the piece on the Bitcoin nonce and the broader Bitcoin mining hub.

The four main causes of stale shares

Almost all stale shares trace to one of four root causes. Understanding which is at play is the first step in fixing the rate.

Network latency between miner and pool

The most common cause is simple distance. Stratum is a TCP protocol, and every share submission round-trips between miner and pool. A miner with 50ms latency to the pool’s Stratum server has 50ms more “stale window” than a miner with 5ms latency. When the pool finds a block (or another miner finds one and the pool switches templates), shares already in flight from high-latency miners are likely to arrive too late.

For most operators, this means picking a pool with servers geographically close to the miner. Foundry runs servers in multiple US regions. AntPool and F2Pool offer Asia, Europe, and US endpoints. Most pools list their Stratum URLs by region; pick the closest one rather than the headline URL.

Block-found timing

Bitcoin produces a block roughly every ten minutes on average, which means every ten minutes the pool switches its template. Shares submitted in the seconds immediately after a block is found are vulnerable to being marked stale, because the miner is still working on the old template until the new job message propagates from the pool.

This produces a small, irreducible floor of stale shares — typically 0.1–0.3% even on a perfectly configured setup. Faster network connections and lower-latency pool selection reduce but cannot eliminate this floor. The deeper mechanics of how templates flow are covered in the piece on block templates explained.

Pool switching mid-share

Configuring a fail-over pool is good practice — most ASICs support three pool entries. But every switch causes a brief spike in stale shares as the miner discards work from the old pool and accepts new work from the new one. Operators who switch pools frequently see chronically elevated stale rates.

The fix is to stop switching unless there is good reason. A monthly evaluation cadence is plenty; weekly or daily switching is almost always counterproductive. Configure fail-overs in priority order and let them sit.

Hardware or firmware glitches

Occasionally a hashboard or chip produces slightly out-of-spec work that the pool accepts but flags as suspect. Bad cables between hashboards and the controller, undervoltage from a sagging PSU, or a firmware bug can all cause this. The signature is a stale rate that climbs over time on a specific unit while other units on the same network stay clean.

Diagnostic steps mirror the broader troubleshooting workflow in the piece on hashrate dropout troubleshooting. Re-seat cables, swap PSUs to test, and confirm firmware version. If stale rate stays elevated on one unit after the obvious fixes, the hashboard or chip itself may be degrading.

What a stale share actually costs

The cost depends on the pool’s payout method. Under PPS and FPPS, the pool pays a fixed expected value per share submitted, but only for accepted shares — stale shares earn zero. So if a miner submits 100,000 shares per day and 0.5% (500) are stale, the miner is missing 0.5% of expected revenue that day. Over a year on a unit grossing $20,000, that is $100. At higher stale rates — 2% or 3% — the same math compounds to several hundred dollars per year per machine.

Under PPLNS, stale shares simply do not get counted in the rolling window. The economic effect is similar but harder to measure on individual blocks. The longer-term implication is the same: every stale share is uncounted work.

At very large fleets, stale share rates become a serious optimization target. A 100-machine operation saving 1% on stale rates is worth tens of thousands of dollars per year. The unpacking of fleet-level economics lives in pieces like the $100,000 mining farm starter and the broader Coin Web Mining catalog.

What a normal stale rate looks like

A well-configured single-machine setup connected to a low-latency pool typically runs 0.1–0.5% stale shares. Two to five percent suggests a real problem — network latency, frequent pool switching, or hardware issues. Above 5% means something needs immediate attention.

Most pool dashboards show stale rate as a percentage over a rolling 24-hour window. Spot checks can be misleading because of variance over short windows. Look at the 24-hour and 7-day rates together. A 24-hour rate that spiked yesterday but is now near baseline is probably a transient event (a network blip, a pool maintenance window, a single bad-luck block); a 7-day rate that has crept upward signals something structural.

How to lower a stale rate

Start with the pool. Latency to the Stratum server is the single biggest controllable factor. Most pools publish ping endpoints or run multiple geographic regions. Pick the closest one. For US miners, that usually means a US East or US West pool URL. For miners in Asia, a Tokyo or Singapore URL. For Europe, an Amsterdam or Frankfurt URL. Manual ping testing from the miner’s network is a 30-second exercise that often saves measurable revenue.

Second, check the internet path. Residential connections with cable or DSL often have higher and more variable latency than fiber. A 50ms ping with 20ms jitter is worse than a steady 30ms ping for Stratum purposes. Network bottlenecks at the home router — overloaded NAT, low-quality WiFi if the miner is wireless — can also add latency. The companion piece on mining network setup walks through the LAN-side considerations.

Third, check the firmware. Some custom firmware versions have introduced bugs that elevated stale rates briefly before patches. Stay on a stable firmware release rather than chasing every new beta. The piece on custom firmware risks covers the trade-offs.

Stale shares vs rejected shares

Operators sometimes conflate the two, but they have different diagnostic paths. Stale shares are valid work that arrived too late. Rejected shares are invalid work — the hash does not actually satisfy the share target the miner claims it does. Rejected shares almost always point to hardware problems: a failing chip producing bad output, an overheating board, a corrupted Stratum submission due to a bad cable.

A clean miner runs both numbers in fractions of a percent. Stale rate over 1% points to network or pool issues. Rejected rate over 0.5% points to the miner itself. Both warrant attention; the order in which to attack them depends on which is higher.

Stratum V2 and stale share reduction

The Stratum V1 protocol, used by most pools today, has known inefficiencies that contribute to stale shares. Stratum V2, championed by Braiins and adopted by Braiins Pool plus some Foundry traffic, addresses several of them — header-only encryption, more efficient job dispatch, and faster failover. Adoption is partial but growing through 2025–2026.

Operators running Stratum V2 firmware (BraiinsOS does this natively; some Bitmain stock firmware supports it on newer units) often see noticeably lower stale rates, particularly on miners connected to large pools. The gain is on the order of 0.1–0.3% reduction in stale share rate. For an industrial operator that is real money; for a single home miner it is marginal.

When to escalate beyond config tuning

Some stale rate problems are not solvable from the miner side. Pool-side outages, transient congestion at major peering points, and infrastructure changes at the pool can elevate stale rates across the pool’s entire user base for hours. Check the pool’s status page or social media before assuming the problem is local. If the stale rate is elevated for multiple unrelated miners pointed at the same pool, it is probably the pool’s side.

For a single miner that stays elevated after all the local fixes, the next step is RMA evaluation. A hashboard that produces consistently more stale work than its siblings is degrading. Document the share counts, snapshot the web UI, and open a support case with the manufacturer or distributor. Coin Web Mining’s support pages cover the RMA process for units bought through the catalog.

References

• Stale shares in Bitcoin mining explained — Braiins
• Stratum V2 and pool latency analysis — Hashrate Index
• Stratum protocol technical overview — Bitcoin Magazine
• Pool latency and stale share guidance — F2Pool

For miners pairing solid pool config with current-generation hardware, the Bitcoin mining hardware lineup covers ASICs that connect cleanly to all major pools at typical home latencies.