A high reject rate can reduce mining revenue because part of the work performed by an ASIC is not accepted by the pool. The miner still consumes electricity and cooling resources, but rejected shares do not contribute to the miner's accepted work under the pool's payout rules. For this reason, operators should look beyond the hashrate shown locally on a miner and also monitor the hashrate and share statistics reported by the pool.

This matters even more at industrial scale. Bitcoin network hashrate was estimated at about 906.20 EH/s on August 13, 2026, while mining difficulty reached 127.48 T after the August 8 retarget. In a competitive environment with tight power margins, even a small persistent reject rate can add up across a large fleet.

What does reject rate measure?

Bitcoin pools use shares to measure the work contributed by connected miners. A share is a proof of work that meets the difficulty target assigned by the pool, even if it does not meet Bitcoin's much harder network target for a valid block. Pools use accepted shares to estimate miners' contributed hashrate and calculate rewards according to the selected payout method.

Not every unsuccessful submission has the same cause. Common share statuses include:

• Accepted share: The pool receives the share and confirms that it meets the assigned share target.
• Stale share: The share was valid for an earlier mining job but arrived after the pool had already issued new work, often after a new block was found or because of network delay.
• Invalid share: The submitted result fails validation. This can be associated with unstable hardware, power delivery, firmware, or aggressive tuning.
• Duplicate share: The same share is submitted more than once.
• Low-difficulty share: The submitted result does not meet the share difficulty assigned by the pool.
• Rejected share: A general pool-side status for submitted work that was not accepted. The rejection reason should be checked before troubleshooting.

Treating every rejected share as a stale share can lead to the wrong diagnosis. A rise in stale shares usually points toward network delay, unstable routing, or delayed job updates. A rise in invalid shares on one machine is more likely to indicate a hardware, cooling, power, firmware, or tuning problem. Operators should review the pool's rejection reason together with miner logs rather than relying only on the overall reject percentage.

How rejected shares affect accepted hashrate and revenue

As a simple approximation:

Accepted hashrate ≈ Local hashrate × (1 − reject rate)

For example, if a 10 PH/s farm runs at a persistent 3% reject rate, its accepted hashrate may be closer to 9.7 PH/s over the same period, even though the equipment continues consuming power at roughly the level required to operate the full 10 PH/s. The exact effect on rewards depends on the pool's payout method, reporting interval, share difficulty, and the types of rejected shares involved.

At larger scale, the difference becomes more visible. A 1 EH/s fleet with a persistent 2% reject rate would, under the same simplified approximation, have about 20 PH/s of work that is not being accepted by the pool. The practical concern is straightforward: electricity is still being consumed while part of the submitted work does not contribute to accepted shares.

Reducing rejects does not change Bitcoin's network difficulty, but it can help a mining operation get more accepted work from the hashrate and electricity it already has available.

The six most common causes of high rejection

1. Latency, packet loss, and unstable routing

A miner needs to receive new jobs promptly and return shares before those jobs become obsolete. High round-trip latency, packet loss, intermittent disconnects, DNS failures, overloaded routers, and poor ISP routing can delay either direction of this exchange. Wi-Fi, satellite links, congested network equipment, and unstable routes can all contribute.

A network-related problem often appears as rising stale shares, reconnect events, timeouts, or "job not found" errors across multiple miners. If an entire facility is affected at the same time, check the WAN connection, router, switch, proxy, DNS, firewall, and route to the pool before assuming that many ASICs failed simultaneously.

Useful checks include:

• Use wired Ethernet for production ASICs whenever possible.
• Measure latency, packet loss, reconnect frequency, and route stability to the pool's official regional endpoints.
• Choose the endpoint that provides the most stable connection, not simply the one that is geographically closest.
• Check router CPU load, NAT or session-table limits, switch errors, DNS resolution, and firewall rules.
• Configure and test official backup endpoints before they are needed.
• Separate mining traffic from management, camera, and office traffic where the network design allows it.

2. Delayed job updates and stale work after a block change

When a new Bitcoin block is found, pools send updated mining jobs to connected miners. A miner that receives the update late or continues submitting work for the previous job can produce stale shares. A small number of stale shares is normal because block discovery and network communication are not instantaneous, but a sustained increase should be investigated.

Mining proxies can also become a bottleneck. In a large farm, an overloaded or poorly configured proxy may delay job distribution to many devices even when the pool connection itself is healthy. Operators can review job-change timing, proxy load, reconnect logs, timeout events, and the delay between receiving a new job and submitting shares for it.

A controlled comparison can help isolate the problem. Move a small group of miners to another official regional endpoint while leaving the rest of the fleet unchanged. If stale shares improve only for that group, route quality or endpoint selection may be involved. If the whole site remains affected, inspect local network and proxy infrastructure.

3. Aggressive tuning, overheating, and degraded hardware

An ASIC can show a high local hashrate while also producing more invalid shares. Overclocking may increase reported hashrate but reduce voltage or timing margin. High inlet temperatures, obstructed airflow, fan failure, unstable power delivery, deteriorating cables, PSU problems, or a failing hashboard can also increase calculation errors.

This pattern often appears on one miner or a small group of miners rather than across an entire site. Compare the affected unit with nearby machines running in the same environment. Check chip temperatures, board status, fan RPM, hardware-error counters, PSU readings, connectors, filters, and airflow paths.

A conservative troubleshooting sequence is:

1. Return the affected miner to a known-good stock or conservative configuration.
2. Change one variable at a time, such as frequency, voltage, fan target, cooling setting, or firmware.
3. Record accepted hashrate, rejection types, power consumption, temperatures, and hardware errors after each change.
4. Repair or isolate a board that continues generating invalid shares under stable settings.

Do not judge a tuning profile only by its local hashrate. A configuration that raises local hashrate but also increases invalid shares, power use, cooling demand, or downtime may reduce overall profitability. Compare the pool's accepted hashrate together with power consumption and operating stability.

4. Firmware, driver, and proxy faults

A sudden rise in rejected shares after a firmware update, autotuning change, proxy migration, or configuration rollout is an important clue. Software changes can alter mining settings, retry behavior, job handling, or device stability.

Maintain a record of firmware versions, tuning profiles, proxy versions, and deployment times. Test updates on a limited group before applying them across the full fleet. If rejects rise after a rollout, preserve logs, roll back a test group, and compare pool-side hashrate and rejection statistics before and after the change. Rebooting the entire fleet immediately can erase useful evidence.

5. Incorrect pool, endpoint, port, or worker configuration

Configuration mistakes can cause authorization failures, low-difficulty shares, malformed submissions, or shares being submitted under the wrong account. Common problems include an incorrect Stratum hostname, port, algorithm endpoint, worker format, password field, or account configuration.

When changing pools or endpoints, verify the connection details against official documentation. Confirm that workers are online under the intended account, accepted shares are increasing, the expected payout account is configured, and rejection alerts remain normal before moving the rest of the fleet.

Avoid relying on copied screenshots, old endpoint lists, or third-party configuration templates when official setup instructions are available. Duplicate worker names and conflicting proxy configurations should also be checked.

6. Pool-side or endpoint instability

Not every rejection event originates inside the mining farm. If otherwise healthy miners at multiple locations show a similar increase in rejects while using the same endpoint, the issue may involve routing, regional endpoint availability, or a pool-side service.

Before contacting support, collect useful evidence: UTC timestamps, affected worker IDs, endpoint and port, rejection categories, latency and packet-loss measurements, reconnect logs, and pool-side hashrate before and after the incident. This helps distinguish a local hardware problem from a wider route or endpoint issue.

ViaBTC's support guidance recommends checking network connectivity, miner temperature, and firmware when rejection is elevated. An older ViaBTC support article notes that rejection rates within 3% can occur under normal conditions, but operators should not treat one generic figure as a universal target. A persistent change from a farm's own baseline, especially when tied to a specific rejection reason, is usually more useful for troubleshooting.

Diagnose the pattern before changing equipment

The fastest troubleshooting path depends on where and when the rejects appear.

Observed patternMost likely causeFirst response One machine is affected while adjacent machines are normalHashboard, PSU, cable, thermal, tuning, or unit-specific firmware issueReview hardware errors and temperatures; return to conservative settings; test cable and network port Every miner at one site spikes at the same timeWAN, ISP, DNS, router, firewall, proxy, or local network eventCheck packet loss, reconnects, router capacity, DNS, and WAN logs Rejects rise after hot weather, overclocking, or a firmware rolloutThermal or voltage margin, or software instabilityRoll back a test group and compare accepted hashrate and reject types Rejects begin after changing pools or endpointsIncorrect endpoint, port, worker format, route, or protocol settingValidate official settings and confirm accepted shares on the intended account Multiple sites using one endpoint are affectedRoute, endpoint, or pool-side issueTest another official endpoint and provide timestamped evidence to support  

A 30-minute response checklist

A disciplined first response can limit lost revenue and prevent several simultaneous changes from hiding the root cause.

1. Classify the rejects. Separate stale, invalid, duplicate, low-difficulty, authorization, and timeout events.
2. Define the scope. Determine whether the issue affects one miner, one rack, one site, or multiple facilities.
3. Establish the timeline. Compare the first spike with firmware deployments, tuning changes, weather, network maintenance, pool migrations, and power events.
4. Compare local and pool-side hashrate. Use a meaningful reporting window rather than a single short-term reading.
5. Test the network path. Measure latency, packet loss, reconnects, and DNS behavior to the active endpoint.
6. Inspect affected devices. Review temperatures, fan speed, board detection, hardware errors, PSU condition, and cabling.
7. Make one controlled change. Roll back one test group, change one endpoint, or restore one miner to stock settings instead of changing several variables at once.
8. Verify recovery. Confirm that reject categories, accepted shares, and pool-side hashrate improve after the intervention.

Prevention: monitor accepted work and reject types

Prevention starts with monitoring the variables that help explain a change. Useful alerts include overall reject rate, stale-share rate, invalid-share rate, connection loss, latency, packet loss, hardware errors, temperatures, and persistent differences between local and pool-side hashrate. A sudden change from the normal baseline may be more important than a single absolute threshold.

Use controlled firmware rollouts, maintain tested backup endpoints, and document known-good configurations for each ASIC model. Farms that use proxies should test whether job distribution remains stable under both normal and failure conditions. Historical baselines by site, miner model, firmware version, and cooling environment can also make abnormal behavior easier to identify.

Protocol improvements such as Stratum V2 can improve parts of the mining connection and job-distribution process, but they do not solve problems such as failing fans, unstable power, or faulty hashboards. The operational priority remains simple: receive current jobs reliably, submit valid shares promptly, and investigate persistent deviations from normal performance.

What a high reject rate is not

Reject rate should not be confused with pool luck, network difficulty, or stale blocks. Pool luck describes statistical variance in block discovery. Network difficulty changes how much work is expected to find a valid Bitcoin block but does not by itself cause an ASIC to submit invalid shares. A stale block is a valid block that is no longer on the active chain; it is different from a stale share submitted to a mining pool.

Keeping these concepts separate helps diagnose revenue changes correctly. A decline caused by higher difficulty or short-term pool luck requires a different response from a rise in rejected shares.

FAQ

What reject rate is too high for a Bitcoin miner?

There is no single threshold that applies to every operation. The more useful signal is a persistent increase above the miner's or site's historical baseline, combined with the specific rejection type. Even a relatively small change can matter if it persists across a large fleet.

Do rejected shares increase electricity consumption?

Rejected shares do not normally cause an ASIC's instantaneous power draw to rise by themselves. The problem is that the miner continues consuming electricity while producing work that the pool does not accept. A higher persistent reject rate can therefore reduce the amount of accepted work obtained from the same operating cost.

Can overclocking raise local hashrate but lower profit?

Yes. An aggressive profile can raise the hashrate shown by the miner while also increasing invalid shares, power use, cooling demand, hardware errors, or downtime. Compare local hashrate with pool-side hashrate and rejection statistics, and consider power consumption and stability at the same time.

Why did rejects increase after switching pools?

Common causes include an incorrect hostname, port, algorithm endpoint, worker format, credentials, DNS resolution, firewall rule, or unstable route. Confirm that the new pool is recording accepted shares under the intended account and that the connection uses the pool's official settings.

Should a miner always use the geographically nearest pool endpoint?

Not necessarily. Geographic distance can affect latency, but route quality and stability also matter. Compare latency, packet loss, reconnect frequency, and route consistency, then choose the official endpoint that performs best in practice.

Conclusion

A high reject rate means that some of the work performed by mining hardware is not being accepted by the pool. The right response is to identify the rejection type, determine whether the problem is limited to one machine or affects a wider part of the fleet, make one controlled change, and confirm the result using pool-side hashrate and share statistics.

For mining operations, the goal is not simply to maximize the hashrate displayed locally. It is to keep hardware stable, maintain reliable pool connectivity, and ensure that as much of the miner's submitted work as possible is accepted. Persistent changes in reject rate should be investigated early, before they become a recurring drag on mining revenue.

References

1. Bitcoin Developer Guide: Mining — Pool mining, shares, and mining workflow.
2. Blockchain.com Bitcoin Explorer — Bitcoin hashrate and difficulty context.
3. ViaBTC Help Center: What if the Rejection Rate is High? — Operational guidance on high rejection rates.