Stale And Rejected Shares in Bitcoin Mining: What They Mean, Why They Happen, and How to Fix Them

1) Quick Definitions

• Share — A proof-of-work result that meets the pool’s share difficulty. Pools use shares to measure your contribution and distribute rewards fairly.
• Stale share — A share submitted too late, typically because the pool has already moved on to a newer block template after a new block was found (or after the template changed).
• Rejected share — A share the pool does not count because it fails validation (common reasons include stale, invalid format, “above target,” duplicates, or protocol/firmware issues).

2) Why Stale Shares Happen (The Real Mechanism)

Pools constantly send miners “jobs” (block templates). When the network finds a new block, the pool must update the template immediately.
Any work submitted for the old template is no longer useful for extending the current chain tip, so it becomes stale.
Pools may also refresh templates to include higher-fee transactions, which can also invalidate older work.

The most common causes of stales

• High latency (long round-trip time to the stratum server)
• Packet loss / unstable internet (shares arrive late or not at all)
• Slow job switching (miner/farm proxy delays applying new jobs)
• Overloaded router / NAT table in larger farms
• Bad routing / VPN causing unpredictable jitter

3) Why Shares Get Rejected (Not All Rejects Are the Same)

“Rejected” is an umbrella label. A miner can do real work and still lose credit if the share cannot be used or cannot be verified correctly.
Many dashboards break rejects into types—understanding the type is the fastest path to a fix.

Common reject types you’ll see

• Stale — Late submission (often latency or connectivity problems).
• Above target / Share above target — The submitted result does not meet the difficulty target (can be software/firmware issues, instability, or incorrect work parameters).
• Low difficulty / Wrong format — The share is not in the expected format or doesn’t meet required parameters (often linked to firmware or protocol issues).
• Duplicate — The same share is submitted more than once (usually software/proxy behavior).

4) Why This Matters: Effective Hashrate and Revenue

Pools pay you for accepted work. Every stale or rejected share is work that does not contribute to your payout calculation.
Even small percentages matter at scale: reducing stales/rejects is often one of the highest-ROI optimizations you can do,
especially when hashprice is tight and margins are thin.

5) Fix Checklist (Do This in Order)

Step 1: Confirm you are mining on the nearest stratum region

• Use the pool endpoint that is geographically closest to your miners (lower latency usually means fewer stales).
• If you operate globally, split miners by region instead of forcing one endpoint for all.

Step 2: Measure latency and packet loss

• Ping the stratum hostname and record average latency and jitter.
• Check for packet loss (even 0.5–1% can hurt share delivery at scale).
• Prefer wired Ethernet over Wi-Fi; avoid consumer-grade extenders for farms.

Step 3: Remove avoidable routing problems

• Disable VPNs unless absolutely necessary.
• Use reliable DNS (and avoid intermittent DNS resolvers that slow reconnections).
• Ensure your router/firewall is not overloaded (NAT table limits are a common silent issue).

Step 4: Stabilize the miner (invalids and “above target” often come from instability)

• Reduce aggressive overclocks; unstable clocks can raise invalid/above-target shares.
• Watch temperatures and throttling—thermal instability can cause calculation errors.
• Update to a stable firmware release (especially if your reject types spike after a change).

Step 5: Check your pool handshake and job flow (logs)

• Verify the miner completes subscription/authorization and receives difficulty updates properly.
• On farms using proxies, confirm the proxy is not buffering jobs too long and is forwarding shares instantly.
• If a single device shows abnormal rejects vs the fleet, isolate: cable/port, PSU, hashboard, firmware, or overheating.

6) Fast Troubleshooting by Symptom

High stales across the entire farm

• Most likely: connectivity, routing, regional endpoint mismatch, or a shared network device bottleneck.

High invalid / above-target on a subset of miners

• Most likely: overclock instability, overheating/throttling, PSU issues, hashboard errors, or a firmware bug.

High duplicates

• Most likely: proxy/miner software sending the same share more than once or mismanaging job IDs.

7) Operational Best Practices

• Use failover endpoints so miners don’t sit idle during network events.
• Monitor reject rate and stale rate as first-class KPIs (alongside TH/s and temperatures).
• Change one variable at a time (firmware, clocks, endpoint, proxy) so you can attribute improvements correctly.
• Keep time accurate on your management systems; while miners handle protocol timing internally, poor network hygiene often correlates with broader configuration drift.