Many miners see a red counter on a status page, a drop in pool-reported hashrate, or a rising reject percentage and conclude that an ASIC has failed. These signals come from different layers of the mining pipeline, and treating them as interchangeable leads to the wrong diagnosis. A hardware error is evidence reported by the miner itself. A rejected share is a decision made by the pool. The two are related only in some cases.

This article separates miner-side telemetry from pool-side share validation, explains what each category can and cannot prove, and outlines a troubleshooting sequence that starts with the correct layer: hardware, firmware or tuning, local network, or pool connection.

Two Different Layers of the Same Mining Pipeline

A mining job passes through several distinct stages before it is counted as accepted work. The ASIC receives a job from the pool and begins hashing locally. Its firmware tracks local conditions — chip count, board temperature, fan speed, local hashrate, and internal hardware-error counters. The miner then submits candidate solutions, called shares, to the pool over a Stratum connection. The pool validates each submitted share against the job it issued and the difficulty target it assigned, then returns an accepted or rejected response, with a reason in the rejected case.

The first two stages are observed only by the miner. The last two stages are observed only by the pool. A fault that originates in one stage does not automatically produce a matching symptom in the other.

What an ASIC Hardware Error Actually Tells You

Hardware-error (HW) counters are miner-side telemetry, typically shown on the ASIC's own status page or firmware interface. According to Bitmain's documentation of its miner status page, a limited number of HW errors can occur while chips are operating at full capacity, and the miner may correct these errors internally and continue hashing without interruption (Bitmain Support). A nonzero HW count by itself is therefore not conclusive evidence that a miner has failed or that the pool is rejecting an equivalent volume of shares.

A rising HW count is worth closer attention when it appears together with other signals, such as:

• lower local hashrate on the same board or unit;
• a reduced detected chip count or an ASIC-status fault indicator;
• a missing or zero-output hashboard;
• a thermal-protection event or fan/PSU fault message in the logs;
• repeated unexpected restarts;
• an increase in invalid-share rejections following a recent frequency or voltage change.

None of these conditions establishes a fixed "normal" HW-error count that applies across models or firmware versions, and this article does not present one. The more useful comparison is against the unit's own recent baseline, not against an assumed industry figure.

What a Rejected Share Actually Tells You

Rejected shares are the umbrella category for any submission the pool does not accept. The specific reason matters more than the total count, because each reason points to a different part of the system.

A stale share is a share that would have been valid for a job the pool has already replaced — commonly because the active blockchain tip changed, or because the miner's connection delayed delivery of the new job or the return of the solution. A stale share is not evidence of a hardware fault; it reflects timing in the connection between miner and pool.

An invalid share is a submission that fails the pool's validation check for the job and target it was given. This category is the one most plausibly connected to an unstable or misconfigured ASIC.

Duplicate and low-difficulty rejections point toward miner software, proxy, or configuration behavior rather than chip-level damage. A duplicate rejection in particular does not necessarily represent newly lost work, since the original submission may already have been accepted.

When Hardware Instability Can Lead to Rejected Shares

An unstable ASIC can produce invalid calculations or malformed submissions, and this is the one area where hardware condition and pool-side rejection are meaningfully linked. Aggressive frequency or voltage settings, elevated chip temperature, marginal power delivery, damaged boards, and firmware incompatibility can all surface first as hardware telemetry and later coincide with an increase in invalid-share rejections.

The relationship runs in one direction only for diagnostic purposes: the presence of hardware errors makes invalid-share review worthwhile, but it does not establish that a simultaneous rise in stale shares is hardware-caused. Stale shares and invalid shares should be investigated separately even when they occur in the same period.

When Rejected Shares Are Not a Hardware Problem

Stale shares are the clearest example of a rejection category that is typically unrelated to chip health. When the Bitcoin network produces a new block, the previous mining job becomes outdated, and pools distribute fresh work based on the new chain tip so that miners continue working toward a valid target (Bitcoin Developer Guide, Mining). If a miner's connection delivers that updated job late, or if its submitted solution arrives after the pool has already moved on, the pool rejects an otherwise valid proof of work as stale.

This condition can affect multiple otherwise healthy miners at a site at the same time, which is a useful diagnostic clue: a hardware failure is ordinarily isolated to one unit, while a shared network path, pool endpoint, or routing issue can raise stale-share counts across many workers simultaneously. ViaBTC's guidance on reducing stale shares identifies pool endpoint selection and network routing, rather than chip condition, as the primary areas to review for this rejection type (ViaBTC).

Comparing Local and Pool-Reported Hashrate

Local ASIC hashrate and pool-reported hashrate are measured differently and should not be compared as if they were the same figure. The ASIC reports its own activity using firmware-defined logic and an averaging period that is not uniform across models. A pool, by contrast, estimates hashrate from the shares it has received over its own reporting window.

ViaBTC's documentation states that its real-time hashrate figure is based on the preceding 10 minutes, while its daily hashrate figure is based on the preceding 24 hours (ViaBTC). A miner that restarted, reconnected, or experienced a brief rejection spike within that window will show a lower pool-estimated figure even if its current local hashrate has already returned to normal. Before concluding that a mismatch reflects a hardware problem, confirm that the two figures cover comparable time windows and that the period does not include a restart, downtime, or a recent endpoint change.

A Rejection-Percentage Calculation, Used Carefully

When a pool displays accepted and rejected share counts for the same defined period, a raw rejection percentage can be calculated as:

Raw rejection percentage = Rejected share count ÷ (Accepted share count + Rejected share count) × 100

This is a count-based diagnostic figure, not a standard profitability metric. It is only meaningful when the accepted and rejected totals cover the same period and comparable categories, and it assumes equal share difficulty across the counted shares; if share difficulty varies, a raw count will not represent the same proportion of underlying work as a difficulty-weighted figure. A reject percentage should not be converted directly into an assumed percentage loss of BTC revenue, since payout method, rejection type, and accounting treatment all affect the outcome differently.

A Practical Troubleshooting Sequence

1. Read the pool's specific rejection reason before reacting to a total reject percentage.
2. Determine scope: is one worker affected, one rack, or the entire site?
3. Review the miner's own status page and logs for chip count, board status, temperature, fan speed, PSU messages, and recent resets.
4. Check what changed recently — firmware update, frequency or voltage adjustment, cooling work, network change, or a new pool endpoint.
5. For stale shares, start with connectivity: confirm the pool's current documented endpoints and compare equivalent operating periods before assuming a hardware cause.
6. For invalid shares, review cooling, power delivery, firmware version, and recent tuning changes; where appropriate, reverting to a previously stable configuration can help isolate the variable.
7. For missing chips, missing boards, persistent thermal shutdown, or PSU faults, follow the manufacturer's documented diagnostic and repair process rather than treating the condition as a connectivity issue.

Conclusion

A hardware error is evidence reported by the miner. A rejected share is a decision made by the pool. The two can share a root cause, but they frequently do not, and diagnosing them with the same checklist leads to wasted effort — reflashing firmware for a routing problem, or chasing a network fix for a failing hashboard. The rejection reason, the miner's own logs, and a matched measurement window together provide a more reliable basis for diagnosis than any single counter viewed in isolation.

FAQ

Does a high HW-error count mean my ASIC is failing?

Not necessarily. Some HW errors can occur during normal full-capacity operation and may be corrected by the miner without affecting continued hashing. A rising count combined with reduced hashrate, a missing board, or thermal alarms warrants closer inspection; the count alone does not confirm failure.

Are stale shares a sign of hardware damage?

Usually not. A stale share is a valid proof of work submitted for a job the pool has already replaced, commonly due to network latency, packet loss, or delayed job delivery rather than a chip-level fault.

Why does my pool-reported hashrate differ from my local hashrate?

The two figures use different measurement methods and time windows. Local hashrate reflects the ASIC's own firmware reading; pool-reported hashrate is a share-based estimate over the pool's stated reporting period. A temporary mismatch following a restart or reconnection does not by itself indicate a hardware problem.

Can a reject percentage tell me how much BTC revenue I lost?

Not directly. A raw rejection percentage is a count-based diagnostic figure that assumes equal share difficulty and a matched reporting period; it does not translate into an exact revenue figure without accounting for rejection type, payout method, and share-difficulty variation.

What should I check first when invalid shares increase after a tuning change?

Review chip temperature, clock and voltage settings, power delivery, and firmware compatibility, and consider reverting to the last known stable configuration before testing further changes.

References

• Bitmain Support, "Miner Status Page Explained" — https://support.bitmain.com/hc/en-us/articles/360013577314-Miner-Status-Page-Explained
• Bitcoin Developer Guide, "Mining" — https://developer.bitcoin.org/devguide/mining.html
• ViaBTC, "How to Reduce Stale Shares With Better Pool URL and Network Routing" — https://www.viabtc.com/en/blog/Mining-how-to-reduce-stale-shares-with-better-pool-url-and-network-routing-735
• ViaBTC, "Mining Pool With Real-Time Hashrate Monitoring: Understanding Measurement Windows and Latency Effects" — https://www.viabtc.com/en/blog/Mining-mining-pool-with-real-time-hashrate-monitoring-understanding-measurement-windows-and-latency-effects-941