WhatsMiner Rejected Shares: Diagnosis and Fixes

WhatsMiner rejected shares are best diagnosed by separating stale work from invalid, duplicate, authorisation and connection failures. Rejected and stale ASIC shares reduce the useful work credited by a mining pool, but the two terms do not describe every rejection.

Rejected shares are work a pool did not credit. Stale shares normally arrived after the job changed; above-target, duplicate, authorisation and other rejects point elsewhere. The fastest repair is to identify the reason first, compare miner and pool evidence, then isolate network, configuration, tuning, firmware or hardware causes in order.

What a rejected share actually means

Reassess WhatsMiner rejected shares whenever network conditions, firmware, tariffs or official guidance changes.

A pool gives your ASIC work and an easier share target. A qualifying hash is submitted as proof of contribution, then accepted or rejected. A reject consumed power but was not normally credited. Timing, an invalid result, duplication, credentials or incompatibility may be responsible. Compare stable local and pool-side hashrate over the same period before declaring a fault; the miner reports chip work while the pool sees valid work it receives.

The main rejection types

When reviewing WhatsMiner rejected shares, separate measured facts from forecasts so the result can be reproduced.

Pools use different wording. 'Stale' at the share level is also different from a stale Bitcoin block. Start with the exact message shown by the pool and miner, then use that provider's current documentation.

Diagnose rejected shares in the right order

Record the fault before changing anything: model, firmware, profile, pool URL, reject type, times, share counts, local and pool hashrate, temperatures and uptime. Preserve the relevant log. Determine the scope. One tuned miner producing invalid work points towards that unit; an entire site becoming stale points towards the WAN, router, endpoint or pool. Several affected units on one switch narrow it further. Check pool status and its current guide. Confirm algorithm, regional Stratum address, port and worker syntax. Use provider-supplied backups, not an unverified forum address. Change one variable and observe it properly.

• Identify the exact reject reason and the time it began.
• Compare local and pool data over the same interval.
• Check whether the pattern affects one miner, a network segment or the full site.
• Verify current pool endpoint, worker syntax and algorithm.
• Review the last deliberate change: firmware, tuning, router, ISP or pool.
• Preserve logs, then test one controlled change.

How to reduce stale shares

A stale share was completed for work that had changed by the time the pool processed it. Distance adds latency, while jitter, loss, congestion and repeated reconnects can be worse than a stable route with a higher average time. Choose the correct regional endpoint and test from the mining network. Ping can expose basic loss but does not prove Stratum health; combine it with accepted-share data and logs. Prefer wired Ethernet. Test without an unnecessary VPN or proxy, inspect cables and ports, and check uplink saturation. Use provider-supplied backups. If the site looks clean, compare another nearby endpoint or reputable compatible pool long enough to separate a local fault from route-specific behaviour.

How to fix above-target, invalid and duplicate shares

If rejects followed aggressive tuning, return to a known-stable stock or approved profile. Watch temperatures, voltage-related logs, chip counts and hardware errors; attractive headline hashrate can hide unstable calculations. Confirm firmware support for the exact control board, variant, algorithm and protocol. Similar names do not make firmware interchangeable. Above-target errors can reflect incompatibility as well as tuning, so more voltage is not a default fix.

For duplicates, remove an unnecessary Stratum proxy in a controlled test and use an approved stable update where the vendor documents a fix. Check whether the pattern follows one miner or every proxy client. For authorisation failures, copy current worker syntax from the pool. Never put a pool password, wallet private key or seed phrase into the miner.

When the ASIC hardware may be involved

Hardware errors and pool rejects are different counters, although an unstable machine can cause both. Investigate rising errors, falling hashrate, missing chips or invalid shares that track temperature and tuning. Check logs for missing chips, board resets, temperature protection, fan or PSU events. Verify power, data cables, airflow and contamination. Do not open energised equipment. If abnormal behaviour survives approved stock settings, use controlled bench diagnosis instead of more voltage or unknown firmware.

What to send the pool, host or repairer

Good evidence turns 'my shares are bad' into a fault somebody can reproduce. Send the minimum information needed and remove secrets.

• Exact miner model, serial reference and control-board type where known.
• Firmware name, version and performance profile.
• Pool and regional endpoint, with wallet or account details redacted where appropriate.
• Time zone and precise start and end time of the incident.
• Accepted, stale, invalid and duplicate counts or percentages by reason.
• Local and pool-side hashrate over the same period.
• Uptime, temperatures, fan speeds, chip count and relevant hardware errors.
• Kernel/miner log and screenshots covering the incident.
• Network path, connection type and changes already tested.

Do not send a seed phrase, private key or reusable account password. A legitimate repair or hosting team can diagnose share behaviour without taking control of your funds.

Conclusion

Rejected shares are symptoms, not a diagnosis. Read the reason, establish the scope and preserve logs. Stales point towards delayed delivery; invalid work towards stability or compatibility; duplicates towards software; and authorisation failures towards pool syntax. Test one change at a time against accepted pool-side work. If correct settings, a clean network and an approved stock profile do not fix it, move to bench diagnosis.

Frequently asked questions

Are a few stale shares normal?

A small number can occur on real networks. Compare the pool's guidance and your normal baseline, then investigate a persistent or rising rate.

Will faster broadband eliminate stale shares?

Not necessarily. Mining uses modest bandwidth; route latency, jitter, packet loss, reconnects and server distance are often more relevant than the advertised download speed.

Can overclocking cause rejected shares?

Yes. An unstable profile can cause invalid calculations or other errors. Return to a known-stable approved setting and compare before changing voltage or firmware again.

Should I reboot the ASIC when rejects rise?

A reboot may clear a temporary condition but can also erase useful context or hide a recurring fault. Capture logs and reason codes first, then reboot only as a controlled diagnostic step.

Why does my miner show full hashrate while the pool shows less?

The miner reports local chip work; the pool estimates work from shares it receives and accepts. Different averaging windows, startup time, stale shares, disconnects or invalid work can create a gap.

Next steps

If abnormal rejects, missing chips or unstable hashrate persist after pool, network and stock-profile checks, send The Mining Shop UK the model, logs and test history. Our Hartlepool lab diagnoses hashboards, PSUs, control boards and firmware.

WhatsMiner rejected shares should be judged with current evidence, measured operating data and a clearly defined decision.