Why Shares Reject and What Your Rig Should Do

A reject is a diagnostic result, not a verdict on your miner. When you ask why shares reject, start with the exact share your rig submitted and the job it was working on. A pool can only accept a share that matches a live job, meets the assigned share difficulty, and is encoded correctly.

For a solo miner, that distinction matters. Your odds of finding a Bitcoin block come from your hashrate and network difficulty. They are the same at every pool. Accepted shares do not improve those odds. Rejected shares can still tell you whether a rig, network, or job handoff needs attention before the rare share that meets the network target arrives.

Why shares reject in solo mining

A share is a small piece of mining work your rig sends back to the pool. The pool checks whether the submitted header solves the job it sent and whether the result is below the target assigned to that rig. A block-winning header is also a share, but one that meets Bitcoin's much lower network target.

Most rejects fall into one of four groups: the share arrived after its job stopped being current, it did not meet the assigned difficulty, the rig sent the same work twice, or the submission could not be read as a valid response to the job. The labels vary by mining software, but the mechanism does not.

A few rejects spread across a long run can be ordinary. A sudden cluster is worth investigating. The pattern tells you more than the total. Rejects that appear immediately after a new block point toward timing. Rejects that begin after a firmware change point toward configuration or hardware. Rejects from one rig while nearby rigs remain clean point toward that rig or its network path.

Stale shares: the job changed before the share arrived

Bitcoin mining work changes when the pool moves to a new block tip or refreshes a template. A rig may still be hashing an older job when the replacement arrives. If it finishes and submits a share for the older job after that job is no longer accepted, the pool rejects it as stale.

This is normal at the edge of a job change. It becomes a problem when the rig receives new work late, applies it late, or has a long round trip to its server. Wi-Fi retries, overloaded home routers, DNS delays, packet loss, and a miner that pauses while processing a job can all extend that window.

Do not confuse a stale share with a bad hashboard. The hash can be valid for the old job. It is rejected because that job is no longer the work the pool can use.

A pool's job handoff matters here, but it cannot make distance disappear. A miner far from its assigned region has a longer round trip. That changes how quickly new jobs reach the miner. It does not change the probability of finding a block.

Low-difficulty shares: the hash missed the share target

A low-difficulty reject means the submitted hash did not meet the target attached to the rig's current job. It is not a near miss for a Bitcoin block. Mining produces hashes across a huge range. Most hashes do not qualify as shares at the selected difficulty.

When low-difficulty rejects occur repeatedly, check whether the miner and pool agree on the active difficulty. Old firmware, a proxy, or a custom configuration can mishandle a difficulty update. An unstable connection can also leave a rig working from an older assignment.

Some pools adjust share difficulty to keep reporting practical. That target is separate from Bitcoin's network difficulty. Network difficulty sets block-finding odds. A pool-side share target controls which partial results the rig reports.

Short disconnects can complicate this. NexusPool (nexuspool.io) holds a rig's difficulty for a few minutes when the rig goes quiet. A brief network interruption does not automatically require the rig to switch to a different share target when it returns. That does not repair a bad connection, but it removes one unnecessary moving part during a short dropout.

Duplicate shares: the same answer arrived twice

A duplicate is usually harmless. The pool already received and processed that exact share, so the second copy has nothing new to prove.

A rig can send duplicates after a timeout when it does not know whether its first submission arrived. A proxy can retry a message. Some firmware behavior around reconnects can repeat queued work. If duplicates are rare, they often describe a retry rather than a mining fault.

If they are frequent, look for an intermittent connection, multiple software layers submitting for the same worker, or a device that reconnects in a loop. The useful question is not whether the pool saw a duplicate. It is why the first response was not visible to the miner.

Invalid or unknown-job shares: check the rig's side first

An invalid submission means the pool could read the message but the values did not match a valid result for that job. An unknown-job reject means the pool no longer recognizes the job identifier the miner referenced. Both can follow an old job, but persistent cases deserve a closer look.

Start with firmware and settings. A miner should have the correct pool address, port, and payout address for the chain it is mining. A Bitcoin rig connects to solo.nexuspool.io:3350. The same port accepts Stratum V1 and encrypted Stratum V2, so a standard V1 ASIC does not need a different connection address just because the pool also supports V2.

Then check the clock, if your firmware exposes it, and remove unnecessary layers. A mining proxy, VPN, filter, or router feature that rewrites or delays traffic gives you another place for jobs and submissions to go out of order. It may be useful in a particular setup, but it is not free.

Hardware can also be the cause. Overclocks that look stable in a hashrate display can produce bad work under sustained load. Heat, weak power delivery, and marginal USB or Ethernet connections can do the same. Return the rig to known-good clocks before treating the pool response as the suspect.

Read the timing before changing settings

Do not change five things after seeing one reject. Record the reject type, the time it occurred, whether the rig had just reconnected, and whether a new block notification had just appeared. That small record is enough to separate many causes.

If stale rejects arrive only around job changes, measure latency and watch how quickly the rig receives new work. If duplicates follow connection loss, inspect the network path and retry behavior. If low-difficulty rejects continue through a stable connection, check the assigned difficulty and firmware version. If invalid shares begin at the same time as a higher clock or hotter room, undo that change first.

The pool should also expose a reason it can stand behind. A useful reject record is tied to the share the firmware actually sent, not a vague health score. NexusPool reads each Bitcoin share as the rig wrote it and returns a reason for each share it reads and rejects. That gives you a starting point for a test, not a request to take a dashboard on faith.

A reject rate needs context

There is no universal reject percentage that proves a setup is healthy or broken. A low-hashrate home miner sends shares less often, so a handful of events can look dramatic. A farm with many ASICs produces enough submissions to reveal a pattern faster. The assigned share difficulty also changes how often a rig reports.

Judge the trend over enough time to include reconnects and block changes. Compare one rig against its own normal behavior before comparing it with a different model, location, or difficulty setting. A Bitaxe on home Wi-Fi and a rack ASIC on wired Ethernet do not have the same failure modes.

The only reject that deserves special attention is one connected to a real block candidate. That event is rare by design. Solo mining is a lottery, and an average wait is not a schedule. The practical work is to keep the path from your rig's hash to the pool visible, current, and testable.

Point the rig at solo.nexuspool.io:3350, watch the reject reasons after it settles, and change one variable at a time. Trust nothing. Verify the reason your rig receives.