Causes of Rejected Shares

A rejected share is a proof the pool, or the local agent, refuses to count. Dashboards do not all name it the same way: some merge stale and rejected, others split them. Start by reading your pool's legend, otherwise you will be comparing two different meters. Rejects then sort into four families, plus a catch-all of pool rules.

Stale (job too old)

The miner produced a correct proof on a job that has already been replaced. The network moved on, or the pool pushed a new template. The hash can be mathematically valid; it arrives too late for the current job.

A non-zero stale rate is normal, since blocks keep arriving. What matters is the comparison: if one machine diverges sharply from the others on the same site and the same pool, the cause sits in the network path, in firmware (long queue, late submit), or in a clumsy failover. See also the article on Stratum jobs and clean jobs.

Duplicate

The pool receives the same share twice: same job, same nonce and extra-nonce, same proof. The usual causes:

• double submit, when an agent retries too eagerly or two sessions stay open;
• a messy pool switch, with two stratum endpoints receiving the same work;
• a clock or queue replaying a submit already sent.

A duplicate earns nothing: it is work already counted once, and the pool will not count it twice.

Difficulty too low (share target not met)

The pool assigns a share difficulty, an easier target than the network target. If the submitted hash does not beat that target, the pool refuses, because the proof is not hard enough for the current contract.

The causes always come back to a disagreement about the target: firmware submitting too early, a misread job, an agent mixing two difficulties after a switch, or a local setting ignoring the difficulty the stratum just announced. Do not confuse this with Bitcoin's difficulty, recomputed every 2016 blocks: here it is the pool's own meter. See the difficulty article.

Difficulty too high (target mismatch)

Less visible in dashboard wording, this is the same family inverted: the miner still believes an old difficulty after the pool announced another, or the operator computes effective hashrate with the wrong share difficulty.

The symptom is recognizable: share count explodes or collapses while local hashrate does not move. Before concluding a hashboard is dead, check that pool-side and machine-side share difficulty refer to the same window.

Clock (time / nTime)

The header carries a timestamp. Some pools or agents reject a share whose nTime sits too far from their clock, or outside the job window. A drifted system clock belongs here: controller without NTP, dead CMOS battery, firmware that freezes time.

If rejects carry a "time", "ntime", or "timestamp" reason, compare the controller clock to a trusted source on the same VLAN, then to the pool's. Exact tolerances depend on the pool and the agent, and are listed in their documentation.

The other rejects

Outside those families sit the pool's own rules: unknown worker, malformed share, extra-nonce out of range, unknown job id, unauthorized IP, temporary ban. Those are identity and protocol messages rather than hall statistics, and they get fixed in account or network configuration.

Procedure to isolate the cause

When a reject rate climbs, this sequence avoids blind diagnosis:

1. Read the exact reject reason in the miner logs and in the pool interface. Without a reason there is no diagnosis, only guesses.
2. Compare the machine to its immediate neighbours: same pool, same switch, same firmware. A problem isolated to one machine and a problem across the site do not have the same causes.
3. Change one variable at a time: pool URL, cable, switch port, worker name, NTP sync.
4. Wait for a long enough observation window before concluding. Over a few minutes, share variance dominates everything you measure.
5. Only escalate to hardware once job, network, and clock are ruled out. A single stale after a block is not a dead hashboard.

One last reflex to avoid: adopting a "normal rate" percentage read somewhere else. Short-window variance, network round-trip time, pool, and firmware all weigh too much for a generic figure to mean anything about your site. Your useful reference is your own fleet last week.