What Is a Reject Rate?
Reject rate is the percentage of submitted shares that a mining pool rejects under its validation rules. For a raw-count calculation, divide rejected shares by total submitted shares, then multiply by 100.
If a miner submits 1,000 shares during a given period and the pool accepts 980 and rejects 20, the reject rate is:
Reject rate = 20 ÷ 1,000 × 100 = 2%
This example assumes equal share difficulty. If share difficulty varies, a raw-count percentage may differ from a difficulty-weighted figure. Use the pool’s displayed rate and documented accounting basis when interpreting its dashboard.
Reject rate is a troubleshooting signal, not a standalone profitability figure. It does not by itself tell you exactly how much Bitcoin revenue was affected or whether your ASIC is faulty. Persistent rejections can mean that some work is not being credited while the machine continues to consume electricity. However, rejection type matters: a rejected duplicate may repeat a share already accepted, rather than represent additional lost hashing work.
Why Pools Use Shares Instead of Waiting for Blocks
Bitcoin mining pools use shares to estimate each miner’s contributed work. A share is submitted proof of work whose hash meets the pool’s assigned target. The pool assigns a share difficulty lower than Bitcoin’s network difficulty, corresponding to a higher numerical target that is easier to meet.
This lets miners submit evidence of work much more frequently than they find blocks. Some submissions also meet the harder Bitcoin network target and can become block candidates, subject to the other block-validation requirements. Ordinary shares help the pool account for contributed work without waiting for each miner to find a block. See the Bitcoin Developer Guide on pooled mining.
What Common Rejection Reasons Mean
The rejection reason usually tells you more about where to investigate than the percentage alone. Labels vary between pool dashboards and miner firmware, so check the specific message where available.
Stale shares. These are submissions for a job the pool no longer accepts, often after a new block or job invalidation. Network latency, packet loss, or reconnects can delay job updates or submissions. A new job does not always invalidate previous jobs, so an older job is not automatically stale.
Invalid shares. These fail the pool’s validation checks. Depending on the error, possible causes include unstable tuning, excessive temperature, power problems, firmware issues, or hardware faults. An invalid-share message is a reason to investigate, not proof that the ASIC is broken.
Duplicate shares. These repeat a previous submission. They can result from software behavior, proxies, retries, or session problems. If the original share was accepted, rejecting its duplicate does not undo that acceptance.
Low-difficulty shares. These do not meet the share difficulty required by the pool. Check difficulty settings and miner or proxy behavior, but do not assume configuration is the only possible cause; firmware or calculation errors can also be involved.
Connection and authorization errors. Incorrect pool addresses, ports, worker details, or other settings may prevent the miner from connecting or obtaining work. These errors are not necessarily submitted shares included in the dashboard’s reject rate. Check them separately, particularly if the worker is offline or has no accepted shares.
For more detailed troubleshooting, see ViaBTC’s guide to rejected mining shares. The Stratum protocol reference also distinguishes share-submission errors from authorization and connection setup.
Why Pool Hashrate Can Differ From Local Hashrate
Local hashrate is the miner’s own estimate of its hashing activity. Accepted pool hashrate is estimated from the shares the pool accepts over a reporting window. These are related measurements, but they are not interchangeable.
ViaBTC documents that its real-time pool hashrate reflects the previous 10 minutes, while its daily hashrate statistic reflects the preceding 24 hours. A newly connected ASIC may therefore show a lower daily pool average simply because it has not been running for the full reporting period. See ViaBTC’s explanation of local and pool hashrate.
Share discovery also varies randomly, so a pool estimate can fluctuate even when the machine runs steadily. Comparing averages over matching periods makes the readings more useful, but does not guarantee they will be identical. A short-term gap alone is not proof of a rejection problem.
Interpreting Your First Readings
Early reject-rate percentages can be misleading when they are based on only a few submissions. A brief increase around a restart or reconnection may settle as more shares are submitted. Check the reporting period and, where available, the number of submissions behind the percentage before drawing conclusions.
Do not wait for a full reporting window to investigate an offline worker, failed authorization, near-total rejection, or repeated invalid-share errors. For a miner that is accepting shares and otherwise operating normally, watch whether the rejection rate settles, remains elevated, or rises over time.
A low, stable rate is reassuring, but read it alongside accepted hashrate and miner logs. A low reject rate does not rule out downtime or work that never reaches the pool.
What to Check When Reject Rate Rises
- Read the rejection message. Identify whether the issue involves stale, invalid, duplicate, or low-difficulty submissions. If there are no accepted shares, check connection and authorization status first.
- Check the likely cause. For stale shares, review latency, packet loss, and disconnects. For invalid shares, check temperature, power, firmware, and recent tuning changes. For duplicates or low-difficulty submissions, review miner and proxy settings and logs.
- Compare affected workers. One affected ASIC suggests checking that machine and its individual connection. A simultaneous rise across several workers suggests checking shared network equipment or the connection path to the pool. These are clues, not definitive diagnoses.
- Change one variable at a time. If the issue began after tuning or a firmware change, returning to a previously stable configuration can help isolate the cause. Avoid changing several settings at once, and compare results over comparable periods.
What Reject Rate Does Not Measure
Bitcoin network difficulty describes how difficult it is to find a block. It adjusts every 2,016 blocks, approximately every two weeks. A change in network difficulty does not by itself explain stale, invalid, or duplicate share submissions.
Pool luck describes variation in actual block discoveries relative to the expected number. It is separate from whether a pool accepts an individual share.
Stale blocks are successfully mined blocks that are not part of the current best blockchain. That is a block-inclusion outcome, distinct from pool share acceptance. Technically, an orphan block is one whose parent has not been processed by the local node. See the Bitcoin glossary.
Monitoring Reject Rate on ViaBTC
ViaBTC’s Dashboard provides configurable hashrate and rejection-rate alerts, with notification options including email, app push, and Telegram. Set the relevant threshold and notification method to support ongoing monitoring. See ViaBTC’s alert setup guide.
ViaBTC’s support guidance describes a rejection rate within 3% as its normal range and recommends checking network connectivity, temperature, and firmware when the rate fluctuates significantly. Treat this as platform-specific guidance, not a universal industry threshold or a reason to ignore persistent errors below 3%. See “What if the Rejection Rate is High?”.
If the issue persists after basic checks, contact pool support with the worker name, miner model, firmware version, pool endpoint, relevant time period, and rejection messages. Include any recent changes that coincided with the problem.
FAQ
Does a high reject rate mean my ASIC is broken?
No. Connection problems, settings, software behavior, and hardware instability can all contribute. Use the rejection message to decide what to check first.
Does a 2% reject rate mean I lost 2% of my Bitcoin earnings?
Not necessarily. The effect depends on share difficulty, rejection type, and the pool’s reward-accounting rules. Duplicate submissions, for example, can be rejected even when the original work was credited. The percentage alone is not an exact BTC-loss calculation.
Is a 0% reject rate required?
No. Occasional rejections can occur during normal operation. Focus on the cause, persistence, and effect on accepted work rather than treating zero as a universal requirement.
Should I wait 24 hours before troubleshooting?
No. The 24-hour window matters when interpreting ViaBTC’s daily average hashrate. It is not a required waiting period for investigating failed connections, repeated errors, or an unusually high reject rate.
References
- Bitcoin Developer Guide — Pooled Mining
- Bitcoin Developer Glossary
- Stratum Protocol Reference
- ViaBTC — Why Is Pool Hashrate Lower Than Local Hashrate?
- ViaBTC — What if the Rejection Rate Is High?
- ViaBTC — How to Set Hashrate or Rejection Rate Notifications
- ViaBTC — Why Are My Mining Shares Rejected?


