Two Signals From Two Different Layers

When a mining operation looks irregular, two different kinds of information often get mixed together: a hardware error counter rising on a miner's control board, and a rejected-share count climbing on a pool dashboard. These are related phenomena, but they are produced by different layers of the mining process and do not measure the same thing.

A hardware error is miner-side telemetry — a condition reported by the ASIC, its control board, or firmware. A rejected share is a pool-side validation outcome — a decision the pool makes about a specific piece of submitted work. Treating one as proof of the other can lead an operator to replace a hashboard when the actual issue is a congested network path, or to dismiss a genuine chip fault because the pool dashboard looks unremarkable.

This article separates the two signals, explains what each one reliably indicates, and outlines a practical order of investigation when only one of the two appears abnormal.

What ASIC Hardware Errors Actually Report

On most ASIC miners, the status interface exposes a hardware-error counter (commonly labeled HW or HW errors) alongside fields such as ASIC status, detected chip count per hashboard, and reported hashrate. Bitmain's own documentation for its status page defines these fields separately: HW reflects hardware or calculation errors reported by the miner, ASIC status of "0" indicates a normal chip, and a nonzero or "X" value can indicate a chip that is not functioning, while a separate field reports the number of working chips detected on a hashboard (Bitmain Support).

A rising HW-error count by itself is not conclusive evidence of hardware failure. Bitmain notes that some hardware errors can occur during normal operation at full computing capacity and may be corrected internally without interrupting hashing. A counter that increases slowly against a stable local hashrate, a full chip count, and normal temperatures is generally a weaker signal than a pattern that combines several indicators at once: falling local hashrate, a hashboard reporting fewer chips than expected, repeated thermal-protection events, fan or power-supply faults, or a device log showing it cannot detect the chips on a board. That combination points toward a device-level condition worth isolating through the miner's own diagnostic logs rather than through pool data.

Because HW-error counters, their reset behavior, and their exact meaning are defined by each manufacturer's firmware, they should not be compared across different ASIC models as if they were a single standardized metric.

What Rejected Shares Actually Report

In pooled mining, a miner does not submit completed blocks to the pool; it submits shares — proof-of-work results that meet the pool's share target. A pool's share target is set numerically higher than the Bitcoin network's block target, which makes it easier to satisfy and corresponds to a lower difficulty than finding an actual block; shares let the pool measure how much work each miner is contributing between blocks (Bitcoin Developer Guide).

A rejected share is the umbrella term for any submitted share the pool does not accept. The specific reason is usually one of several subcategories, not a synonym for "rejected share" itself:

• Stale share — work that was valid for an earlier mining job but arrived after that job was no longer current.
• Invalid share — a submission that fails the pool's validation checks.
• Duplicate share — the same share submitted more than once.

Bitmain describes a mining pool's rejection rate as the ratio of data rejected by the pool to the total data sent by the miner, and identifies network instability as a principal cause of an elevated rate (Bitmain Support). This matters for diagnosis: a cluster of stale shares most often reflects timing or connectivity conditions between the miner and the pool endpoint, not a chip-level fault. Invalid shares, by contrast, can sometimes follow unstable mining settings, firmware issues, or inconsistent power delivery — conditions that also affect hardware behavior — so a rise in invalid shares is a more reasonable (though still not conclusive) prompt to check the device itself.

Where a pool reports accepted and rejected counts for the same period, a raw rejection percentage can be calculated as:

Rejected share count ÷ (Accepted share count + Rejected share count) × 100

This figure is only meaningful when accepted and rejected counts cover the same time window and the same share-difficulty setting; if share difficulty changed during the period, raw counts no longer represent comparable amounts of work. The result should also not be read as a direct percentage of lost BTC revenue, since revenue depends on actual accepted work, pool payout calculation, and timing of blocks found, not on a simple share ratio.

Why the Two Signals Get Conflated

The confusion between hardware errors and rejected shares usually comes from two habits: assuming that any red indicator on any screen means the same kind of problem, and comparing numbers that were measured over different windows or by different systems. A miner's local display reports what the device itself observed — its own chip status, its own error counters, its own calculated hashrate. A pool dashboard reports what the pool observed from the shares it received — which depends on the miner's output but also on the network path, the reporting interval, and the pool's own validation logic.

The two can move together when an actual hardware problem causes the miner to produce unstable or invalid work that the pool then rejects. But they can also move independently: a perfectly healthy ASIC can show a high stale-share rate because of a congested or distant pool endpoint, and a miner with early hardware instability can still show an unremarkable rejection rate if the pool has not yet received enough affected submissions to make the pattern visible.

A Practical Diagnostic Approach

Rather than reacting to either number in isolation, it helps to read the specific signal and check it against a short set of questions before concluding what is wrong.

If the hardware-error counter is rising, check whether local hashrate, chip count, and temperatures remain stable. If they do, the counter alone is weaker evidence of a fault. If local hashrate is falling, chips are missing, or thermal or fan faults are also logged, the device itself warrants closer inspection, starting with the miner's own logs.

If rejected shares are rising, check which subcategory dominates. A pattern concentrated in stale shares points first toward the connection path — the chosen pool endpoint, routing, or reconnect behavior — rather than the hashboards. A pattern concentrated in invalid shares is a more reasonable prompt to review recent firmware or tuning changes, power stability, and cooling, alongside the device's own error logs.

In either case, confirm whether the pattern affects a single worker or many workers connected through the same path. A problem isolated to one device points toward that device; a problem affecting multiple otherwise independent miners at the same time points toward a shared element such as the network connection or pool endpoint.

Why Local and Pool Hashrate Figures Can Disagree

A related source of confusion is a mismatch between the hashrate shown on a miner's own display and the hashrate shown on a pool dashboard. These are not interchangeable figures: local hashrate is a device-reported estimate using the manufacturer's own refresh and averaging method, while a pool's hashrate is an estimate derived from the shares it actually received over a stated window.

ViaBTC's dashboard, for example, calculates real-time hashrate as a rolling average over the preceding 10 minutes and daily hashrate as a rolling average over the preceding 24 hours (ViaBTC). After a restart or brief disconnection, a miner's local hashrate can return to normal within minutes, while the pool's 24-hour figure can remain lower for longer simply because the earlier downtime is still inside that rolling window. This is a measurement-window effect, not independent evidence of a hardware error or a pool-side problem, and it should be checked by comparing figures over matching time periods before either signal is treated as confirming a fault.

Conclusion

A hardware-error counter and a rejected-share count answer different questions: one describes what the ASIC itself reported, the other describes what the pool decided about submitted work. Reading the specific rejection reason, checking whether a hardware signal is accompanied by other device-level symptoms, and aligning measurement windows before comparing figures will generally lead to a more accurate diagnosis than treating every red indicator as the same kind of failure.

FAQ

Does a rising HW-error count always mean a hashboard is failing?

Not necessarily. Some hardware errors can occur during normal operation and be corrected without interrupting hashing. A persistent rise accompanied by falling local hashrate, missing chips, or thermal and fan faults is stronger evidence of an actual device problem than the counter alone.

Are stale, invalid, and duplicate shares three equal types of problems?

They are all subcategories of the broader "rejected share" outcome, not separate peer metrics. Each points toward a different likely cause: stale shares toward timing or connectivity, invalid shares toward possible hardware or configuration instability, and duplicate shares toward repeated submissions from software or connection behavior.

Can I use a rejection percentage to estimate lost mining revenue?

A raw rejection percentage, calculated from matching accepted and rejected share counts over the same period, describes the share of submitted work the pool did not accept. It is not a standardized revenue-loss metric, since actual payouts depend on pool accounting, share difficulty, and block-finding timing rather than on the raw ratio alone.

Why does my miner's screen show a different hashrate than the pool dashboard?

The two use different measurement methods and time windows. A miner's local display is a device-reported estimate, while a pool dashboard reflects shares actually received over a stated rolling period. Differences are more likely a reporting-window effect than evidence of a hardware or pool fault, particularly after a recent restart.

References

• Bitcoin Developer Guide, "Mining" — https://developer.bitcoin.org/devguide/mining.html
• Bitmain Support, "Miner Status Page Explained" — https://support.bitmain.com/hc/en-us/articles/360013577314-Miner-Status-Page-Explained
• Bitmain Support, "The Rejection Rate of Mining Pools" — https://support.bitmain.com/hc/en-us/articles/5220664696473-The-rejection-rate-of-mining-pools
• 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