The rejection rate of mining pools

Reject rate is the share of the work your miner submits that the pool refuses to credit — counted as rejected shares divided by total shares submitted. Your ASIC does not mine “coins” directly; it streams a firehose of shares (proofs that it found a hash below the pool’s target) to the pool over the Stratum protocol. The pool pays you on accepted shares. Every rejected share is real electricity spent on work that earns nothing, so the reject rate is a direct read on how much of your hashrate is actually reaching the pool as paid work.

A small reject rate — a fraction of a percent up to a percent or two — is normal and unavoidable on any pool. The rule of thumb: if your pool-side (effective) hashrate tracks your hardware hashrate, a low reject rate can be ignored. It becomes a problem when it climbs to several percent and stays there, or when your effective hashrate at the pool drifts noticeably below what the miner reports locally. That gap is lost revenue.

Reject rate vs. hardware error rate — don’t confuse them

These are two different numbers and they have different causes:

• Reject rate (pool-side): shares the miner sent that the pool threw out. This is almost always a networking, timing, or configuration problem — not a broken chip.
• HW error rate (hardware, “HW” counter): bad nonces the control board caught coming back from the ASICs before they were ever submitted. Rising HW errors point at a failing hashboard, over-aggressive overclock, heat, or a bad power domain — a repair issue, not a pool issue.

Before you chase a reject problem, confirm which counter is actually elevated in your miner’s kernel log or dashboard. Fixing the wrong one wastes time.

Why shares get rejected — the four codes

When a pool refuses a share over Stratum it returns a numeric error. Knowing the code tells you exactly where to look:

• Stale / “Job not found” (code 21): the single most common reject. Your miner submitted a valid share, but for a job the pool has already retired. Every time a new block is found anywhere on the network, the pool pushes a fresh job with clean_jobs set, and any in-flight work for the old job becomes worthless. The more latency between your miner and the pool, the wider that window and the more stales you accumulate.
• Low difficulty share (code 23): the share didn’t meet the pool’s current target. Usually a difficulty-negotiation hiccup, a mid-session mining.set_difficulty change your firmware handled poorly, or a flaky connection corrupting submissions.
• Duplicate share (code 22): the pool already has that exact share. Points at a misbehaving proxy, a double-submitting firmware bug, or two workers colliding on the same credentials.
• Unauthorized worker (code 24): the worker name/credentials aren’t authorized. A configuration error, not a network one — fix the worker string in the pool settings.

Note that your miner’s local accepted/rejected tally will never match the pool’s dashboard perfectly. The pool validates independently and network latency creates edge-case discrepancies. Always trust the pool-side numbers for revenue decisions.

The three network hops where rejects are born

Between your ASIC and the pool’s server, a share crosses three links. High reject rates trace back to instability in one of them:

1. Your local network: the most common and most fixable culprit. Interference, a marginal or loose Ethernet cable, a cheap switch, or Wi-Fi bridges dropping packets. Miners should always be on hardwired Ethernet, never Wi-Fi.
2. Your ISP / upstream route: unstable routing nodes, packet loss, or high jitter on the path out of your building add latency that widens the stale-share window.
3. The pool server: an overloaded, distant, or misbehaving pool endpoint. If a whole hashcenter’s worth of miners on one pool all spike at once, the problem is upstream of you.

Because reject-inducing latency compounds across all three hops, geographic distance to the pool’s stratum server is often the biggest lever. Pointing a miner in North America at an Asia-based stratum endpoint can add hundreds of milliseconds of round-trip time and visibly raise stales. Most serious pools publish regional stratum URLs — always pick the one closest to your physical location.

How to diagnose and cut a high reject rate

1. Read the kernel log. In the miner’s web UI, find the reject reasons. A log dominated by “stale” / “job not found” is a latency/timing problem; “low difficulty” or “duplicate” points at config, firmware, or a bad proxy.
2. Measure latency to the pool. From a machine on the same network, ping or trace the stratum host. Consistent low round-trip time is what you want; spikes and packet loss are your smoking gun.
3. Switch to the nearest regional stratum server. This alone resolves most stale-share problems.
4. Inspect the physical link. Re-seat and, if in doubt, replace the Ethernet cable between miner and switch. Keep data cabling away from PSU and high-current DC leads, which radiate interference. Bypass any powerline/Wi-Fi bridge.
5. Check difficulty behavior. If the pool supports variable difficulty (vardiff), let it settle; a fixed difficulty set far too low floods the link with shares and invites stales, while too high starves your stats. Match difficulty to the miner’s hashrate.
6. Look at firmware. Buggy or mismatched firmware handles job switches and difficulty changes poorly. A clean, current firmware build often drops the reject rate on its own.
7. Test one variable at a time and give each change a few hours — reject rate is noisy over short windows.

Stratum V2 cuts stales at the protocol level

The legacy Stratum V1 protocol delivers new jobs relatively slowly, which is precisely what creates stale shares. Stratum V2 delivers work dramatically faster — roughly single-digit-millisecond job delivery when paired with a local template source, versus the hundreds of milliseconds typical of V1 — which shrinks the stale window and, on modern setups, reduces bandwidth substantially through binary framing. Native SV2 support currently ships on BraiinsOS+ (industrial Antminers) and on AxeOS / ESP-Miner v2.14.0 and later (Bitaxe). If your pool and firmware both support it and stales are your dominant reject reason, moving to SV2 is a real fix, not a marginal one.

How to confirm it worked

• Reject rate on the pool dashboard settles back to a fraction of a percent and stays there over a full day.
• Your effective (pool-side) hashrate converges with the hardware hashrate the miner reports locally — the gap you were losing to rejects closes.
• The kernel log stops filling with “stale” / “job not found” entries.

When it isn’t the pool

If reject reasons are minimal but your HW error counter is climbing, your effective hashrate is being eaten by hardware, not networking — a hot or failing hashboard, an unstable overclock, or a weak power domain. That is a bench problem, not a pool problem. Roll back any overclock, verify airflow and intake temps, and if it persists, work the hashboard down chip-by-chip. Persistent rejects the customer service of a pool can’t explain, combined with rising HW errors, mean it’s time to open the machine up.

Related: Trace hardware faults with the ASIC fault finder, look up terms like hashrate in the mining glossary, pull your model’s setup docs from the miner manuals library, or start a repair if a failing hashboard is dragging your effective hashrate down.