Reject Rate

The reject rate is the fraction of shares a mining pool refuses to credit, expressed as a percentage of all shares your miner submits. A low, steady reject rate is healthy; a rising one signals a configuration, connectivity, or hardware problem worth investigating. Every rejected share is hashing work you paid for in electricity and earned nothing on, so operators watch this number as closely as hashrate itself — it is effectively the error rate of your connection to the mining pool.

What gets rejected, precisely

Under Stratum V1, a rejected share comes back as an error on the mining.submit response, and the standard error codes name the buckets directly: code 21 "Job not found" (a stale job ID — the pool already moved on), code 22 "Duplicate share" (already submitted, often a firmware or proxy bug), code 23 "Low difficulty share" (below the assigned target, typically a miner that missed a difficulty change), code 24 "Unauthorized worker," and code 25 "Not subscribed." The most common by far is the stale share: your hardware found a valid solution to a job the pool had already replaced. When a pool sends new work with clean_jobs set to true — as happens every time a new block is found — every share in flight against the old job becomes instantly stale. Stratum V2 keeps the same taxonomy with explicit reject strings such as stale-share and too-low-difficulty.

What is an acceptable rate

For a well-connected miner, a reject rate in the low single digits — often cited around one to two percent — is normal, and some rejects are unavoidable physics: blocks arrive at random moments, and any share in flight during the changeover is stale no matter how good your setup is. Chasing an absolute zero is unrealistic. Sustained higher values usually trace to one of three causes: high network latency to the pool (distant server, congested uplink, flaky Wi-Fi), an overheating or aggressively overclocked hashboard producing invalid hashes, or firmware that is slow to abandon old jobs when new work arrives. The target your shares must beat is set by the pool's share difficulty, and a miner that fails to apply a mining.set_difficulty update will suddenly shower the pool with low-difficulty rejects.

Diagnosing a rising reject rate

Work outward from the cheapest checks. First, latency: ping the pool endpoint and switch to the geographically nearest server; every millisecond of round-trip widens the stale window. Second, the dashboard breakdown: a pile of stale shares points at the network or slow job switching, while low-difficulty or hardware-error rejects point at the machine itself — heat, voltage, or a marginal board. Third, compare the miner's own accept/reject counters against the pool's. They rarely match perfectly, and modest divergence is expected: setups that validate locally before submitting can accept a share the pool later rejects, and latency skews both counts. Large divergence, though, suggests a proxy or firmware issue between you and the pool. Fixing a two-point reject-rate problem is one of the highest-ROI tune-ups in home mining: it is pure recovered revenue with zero additional power draw.

Full open-data reference: Stratum Error-Code Reference — CSV / JSON + REST API, CC BY 4.0.