Every hash your ASIC computes costs you electricity. When that hash gets rejected by your mining pool, you just burned watts for nothing. Rejected shares are the silent drain on your Bitcoin mining operation — invisible on your power bill, painfully visible in your payout reports.
If you are running an Antminer in your basement, a Bitaxe on your desk, or a fleet of S21s in a hosted facility, rejected shares eat into your effective hashrate. In a network pushing past 800 EH/s with difficulty above 110 trillion, every accepted share matters. The block reward sits at 3.125 BTC post-halving — you cannot afford to waste work.
This guide breaks down what rejected shares actually are at the protocol level, why they happen, how to diagnose them, and — most importantly — how to eliminate them. No fluff. No altcoin distractions. Bitcoin only.
What Are Mining Shares, Really?
A share is proof that your miner performed valid computational work. When your ASIC hashes a block header candidate and the resulting hash falls below a certain target, that is a share. The pool sets a lower difficulty target than the actual Bitcoin network difficulty so miners can submit proof of work more frequently — this is how pools estimate your hashrate contribution and distribute rewards proportionally.
Think of it this way: the Bitcoin network needs a hash below an astronomically difficult target to find a block. The pool says, “Show me hashes below this easier target so I can track how much work you are doing.” Each of those easier solutions is a share.
Accepted Shares
An accepted share meets all the pool’s criteria: it is a valid hash, submitted on time, for the correct job (block template), and at or below the pool’s difficulty target. These shares count toward your payout. The more accepted shares you submit, the larger your slice of the pool’s block reward when a block is found.
Rejected Shares
A rejected share is work your miner performed that the pool refuses to credit. Your ASIC burned real electricity computing that hash, but the pool says “no” — it does not count toward your payout. The reasons vary, but the result is always the same: wasted energy, wasted time, reduced effective hashrate.
Types of Rejected Shares
Not all rejections are created equal. Understanding the type tells you exactly where to look for the fix.
Stale Shares
This is the most common type. A stale share was valid when your miner computed it, but by the time it reached the pool, the pool had already moved on to a new block template. Someone else found a block, the pool issued new work, and your share arrived referencing the old job. The pool has no use for it.
Stale shares are a latency problem — the gap between your miner computing the share and the pool receiving it was too long. At 800+ EH/s network hashrate, new blocks appear roughly every 10 minutes on average, but block template updates from pools happen far more frequently as transactions enter the mempool. Every millisecond matters.
Duplicate Shares
Your miner submits the same share twice. This typically indicates a firmware bug, a misconfigured worker, or a connectivity issue causing retry loops. The pool already has the share, so the second submission gets rejected. It wastes bandwidth and can flag your worker in some pool implementations.
Above-Target Shares
The share’s hash does not meet the difficulty target the pool assigned to your worker. This happens when there is a mismatch between the difficulty your miner thinks it should be working at and what the pool expects, or when hardware errors produce incorrect hash computations. On variable-difficulty pools, this can also occur during difficulty adjustment transitions.
Invalid Shares
The share contains fundamentally incorrect data — a malformed block header, wrong Merkle root, or a hash that simply does not validate. This almost always points to hardware failure: a failing ASIC chip, memory errors, or overheating causing computation errors. If you are seeing invalid shares, something is physically wrong with your machine.
Why Rejected Shares Happen: Root Causes
Network Latency
The number one cause of stale shares. Every millisecond of round-trip time between your miner and the pool server is a millisecond where a new block could be found, rendering your in-flight share stale. WiFi connections, congested home networks, routing through distant servers, and cheap networking equipment all add latency.
For context: a pool server in the same country as your miner might give you 20-50ms round-trip time. A pool on another continent could be 200-400ms. At the pace of Bitcoin mining in 2026, that difference translates directly into stale share percentage.
Hardware Issues
Failing hashboards, degraded ASIC chips, insufficient cooling, and power supply instability all produce invalid or above-target shares. An ASIC chip running too hot does not just slow down — it produces incorrect computations. A hashboard with dead chips may report normal operation while generating garbage data.
This is where professional ASIC repair becomes critical. At D-Central, we have repaired thousands of miners since 2016. We see the same pattern repeatedly: a miner runs for months with a 3-5% reject rate because one hashboard has a failing chip. The operator assumes “some rejects are normal” and bleeds money. A single board-level diagnostic and chip replacement fixes the problem entirely.
Overclocking Gone Wrong
Pushing your ASIC beyond factory specs increases hashrate but also increases error rates. There is a sweet spot where the extra hashrate from overclocking outweighs the rejected shares it creates. Go past that point and your effective hashrate actually drops despite higher reported hashrate. The miner’s dashboard says 150 TH/s but the pool sees 140 TH/s effective because 7% of shares are getting rejected.
This is especially relevant for Bitaxe operators who love to push their open-source miners. Overclocking a Bitaxe Supra or Ultra is part of the fun, but monitor your pool-side effective hashrate — not just the number on AxeOS. If your pool reports significantly less than what AxeOS shows, your overclock is too aggressive.
Pool Server Distance and Selection
Mining pools operate servers across multiple regions. If you are in Canada mining on a pool with its nearest server in Singapore, you are adding 200+ milliseconds of latency to every share submission. Most major pools (Ocean, Braiins, DEMAND, CK Pool) offer North American endpoints. Use them.
For solo miners running Bitaxe devices on Solo CK Pool or similar — the same principle applies. Your tiny hashrate means every single share is precious. Do not waste them on stale submissions due to poor server selection.
Firmware and Software Bugs
Stock firmware on many ASIC miners has known bugs that cause duplicate share submissions or incorrect difficulty handling. Aftermarket firmware like Braiins OS+ or Vnish often resolves these issues while also providing better monitoring and autotuning capabilities. For Bitaxe, keeping AxeOS updated is essential — each release addresses bugs that can cause unnecessary rejections.
The Real Cost of Rejected Shares
Let us do the math. Say you operate an Antminer S21 at 200 TH/s, consuming 3,500W. At $0.07/kWh (a reasonable Canadian hydro rate), that is $5.88 per day in electricity.
If your reject rate is 2%, you are effectively mining at 196 TH/s but paying for 200 TH/s. That 2% reject rate costs you roughly $0.12 per day — about $43 per year per machine. Running 10 machines? That is $430/year going straight to waste. And that assumes only 2% — we have seen home miners unknowingly running at 5-8% reject rates, which scales the loss proportionally.
Now factor in the current block reward of 3.125 BTC. Every fraction of effective hashrate lost to rejected shares is a fraction of your statistical share of that reward gone. In a network above 800 EH/s, the margins are already razor-thin for home miners. Rejected shares make them thinner.
Impact on Pool-Reported Hashrate
Your miner’s local dashboard shows your raw hashrate. The pool shows your effective hashrate — after rejected shares are subtracted. A persistent gap between these two numbers is the clearest indicator that you have a reject problem. If your S19j Pro reports 104 TH/s locally but the pool consistently shows 98-100 TH/s, you have a ~4% reject rate that needs investigation.
How to Diagnose Rejected Shares
Step 1: Check Your Pool Dashboard
Every reputable mining pool displays your accepted/rejected share counts and your reject percentage. This is your ground truth. The miner’s own interface may not report rejects accurately — always trust the pool’s numbers.
Step 2: Calculate Your Rejection Rate
Rejection Rate = (Rejected Shares / Total Submitted Shares) x 100
Below 0.5% — excellent. You are running a tight operation.
0.5% to 1% — acceptable, but worth investigating if you want to optimize.
1% to 3% — something needs attention. Check network, firmware, and hardware.
Above 3% — you are bleeding money. Act immediately.
Step 3: Identify the Rejection Type
Most pools label rejections. “Stale” points to latency. “Invalid” points to hardware. “Duplicate” points to firmware or connectivity. “Above target” points to difficulty configuration. The label tells you where to focus your troubleshooting.
Step 4: Monitor Over Time
A single spike is not a crisis — network events, pool restarts, and Bitcoin block timing variance all cause temporary rejection spikes. Look at 24-hour and 7-day averages. Persistent elevation is the signal that something is structurally wrong.
Eliminating Rejected Shares: The D-Central Playbook
We have been fixing miners since 2016 — long before most people had heard of home mining. Here is what actually works.
Fix Your Network First
- Use Ethernet, not WiFi. This is non-negotiable for ASIC miners. WiFi adds latency, jitter, and packet loss. A $5 Ethernet cable eliminates an entire category of rejects.
- Use your pool’s nearest server. If you are in Canada, use the North American endpoint. Check your pool’s documentation for server locations.
- Prioritize mining traffic. If your home network is shared, configure QoS on your router to prioritize your miner’s traffic. Stratum connections use minimal bandwidth but are extremely latency-sensitive.
- Use Stratum V2 where available. Stratum V2 reduces the data exchanged between miner and pool, cutting latency and stale rates. It also gives you the ability to construct your own block templates — a win for decentralization.
Maintain Your Hardware
- Clean your miners regularly. Dust buildup causes overheating, which causes computational errors, which causes invalid shares. Compressed air every 3-6 months depending on your environment.
- Monitor chip temperatures. Most firmware exposes per-chip temperature data. Chips running consistently above their rated temperature will produce more errors. If cooling is insufficient, consider upgrading fans or using a Bitcoin space heater enclosure that manages airflow properly.
- Get failing boards repaired. A hashboard producing elevated rejects will not fix itself. D-Central’s ASIC repair service performs board-level diagnostics and chip replacement. We have seen single-chip repairs drop a miner’s reject rate from 5% to under 0.3%.
- Check your power supply. An underpowered or failing PSU causes voltage drops under load, which manifests as computation errors and invalid shares. Use a PSU rated for your miner’s actual draw, not just its nominal spec.
Optimize Your Firmware
- Update to the latest stable firmware. Firmware updates frequently fix share submission bugs and improve difficulty handling.
- Consider aftermarket firmware. Braiins OS+ offers autotuning that finds the optimal balance between hashrate and efficiency (and by extension, reject rate). For Antminers, this is often the single biggest improvement you can make.
- For Bitaxe: keep AxeOS current. The open-source community actively fixes bugs that cause rejections. Check the GitHub repository for your specific Bitaxe model.
Overclock Responsibly
- Monitor pool-side effective hashrate, not local hashrate. Your overclock is only beneficial if pool-side effective hashrate is higher than your stock effective hashrate. If rejects eat the gains, dial it back.
- Increase in small increments. Push frequency or voltage by small steps. Run for 24 hours at each step. Check pool-side rejects before going further.
- Know the thermal headroom. Overclocking increases heat output. If your cooling cannot handle it, you will hit thermal throttling or error states that generate invalid shares.
Rejected Shares in Solo Mining
If you are solo mining — whether on a full ASIC through Solo CK Pool or on a Bitaxe hunting for that legendary solo block — rejected shares matter even more. In pool mining, a few rejected shares reduce your proportional payout slightly. In solo mining, every single share is a lottery ticket. A rejected share is a lottery ticket you paid for but never submitted.
Solo Bitaxe miners should pay particular attention to their setup. A Bitaxe Supra running at ~500 GH/s is already facing astronomical odds against 800+ EH/s of network hashrate. Losing 2% of those shares to rejections because of a WiFi connection makes already-long odds even longer. Ethernet cable. Nearest pool server. Latest AxeOS firmware. These are small changes that protect every hash. Because in solo mining, every hash counts.
When to Call in the Professionals
If you have optimized your network, updated your firmware, and your reject rate is still above 1%, the problem is almost certainly hardware. Board-level issues — failing chips, bad solder joints, degraded thermal interface material — require diagnostic equipment and repair expertise.
D-Central has been the go-to ASIC repair service in Canada since 2016. We have repaired everything from vintage S9s to the latest generation S21s. A miner with a persistent reject problem is a miner with a fixable hardware issue. Do not let it bleed your profits month after month.
Browse our full catalog of miners, parts, and accessories in our shop, or visit the Bitaxe Hub if you are building your open-source solo mining setup.
Frequently Asked Questions
What is a normal rejected share rate for Bitcoin mining?
Below 0.5% is excellent and indicates a well-optimized setup. Between 0.5% and 1% is acceptable. Anything above 1% consistently deserves investigation. Above 3% means you are losing real money and should troubleshoot immediately — starting with network latency, then firmware, then hardware diagnostics.
Do rejected shares still use electricity?
Yes. Your ASIC consumes the same power whether it produces an accepted share or a rejected one. The computation happens locally before the share is submitted. A rejected share means you paid for the electricity to compute work that generated zero return. This is why reject rate directly impacts your mining profitability.
Can WiFi cause rejected shares?
Absolutely. WiFi adds latency, jitter, and is prone to packet loss — all of which increase stale share rates. For any ASIC miner (or even a Bitaxe), use a wired Ethernet connection. It is the single easiest fix for elevated stale share rates and costs next to nothing.
How do rejected shares differ in solo mining versus pool mining?
In pool mining, rejected shares reduce your proportional share of pool rewards slightly. In solo mining, every share is an independent attempt to find a block. A rejected share in solo mining is a wasted block attempt — a lottery ticket you paid for but never entered. For solo miners, minimizing rejects is even more critical because you need every possible attempt counted.
Does overclocking increase rejected shares?
It can. Overclocking pushes ASIC chips beyond factory specifications, which increases heat output and error rates. There is a sweet spot where the extra hashrate outweighs the additional rejects, but going beyond it actually decreases your effective hashrate. Always monitor your pool-side effective hashrate — not just your local reported hashrate — when overclocking.
How do I fix a high rejected share rate on my Bitaxe?
Start with the basics: use Ethernet instead of WiFi, select the nearest pool server, and ensure AxeOS is updated to the latest version. If you have overclocked, dial back your frequency settings and monitor for 24 hours. Check that your 5V power supply (5.5×2.1mm barrel jack for Supra/Ultra/Gamma) is delivering stable, adequate power — a weak PSU causes computation errors. Visit our Bitaxe Hub for comprehensive setup and troubleshooting guides.
Can D-Central repair a miner with high reject rates?
Yes. Persistent high reject rates that survive network and firmware optimization almost always indicate a hardware issue — typically a failing ASIC chip, bad solder joint, or degraded thermal interface on a hashboard. D-Central’s ASIC repair service performs board-level diagnostics and component-level repair. We have been doing this since 2016 and have repaired thousands of miners across all major manufacturers.
