Why Is My ASIC Miner Rejecting Shares? Stale and Rejected Share Troubleshooting

Published: 2026-08-29 Updated: 2026-08-29 Evidence checked: 2026-08-29

Rejected shares mean the pool did not credit submitted work. Start by comparing accepted, rejected, and stale counter changes over the same timed window on both the miner and pool dashboard. Stale shares usually point toward delayed job changes or network-path problems; other rejects can follow endpoint, authorization, firmware, temperature, or hardware issues. Change one variable at a time, then repeat the same measurement before switching pools or replacing parts.

Start with the counters, not a guessed percentage

A reject counter is only useful when you know what it includes. On an ANTMINER status page, Accepted is work the pool accepted, while Stale is work submitted for a block that had already been solved. The same page exposes separate last-difficulty fields for accepted, rejected, and stale shares. Bitmain's status-page glossary is useful when those abbreviations are unfamiliar.

Pool dashboards can group the numbers differently. Some show stale work as its own category; others present one combined rejection rate or use a reason label from the pool. Write down the definitions shown by both interfaces before comparing them. Do not add a miner's stale count to a pool rate unless the pool says the rate excludes stale work.

For one clearly defined window, calculate a local diagnostic rate as:

Observed non-accepted rate = (rejected delta + stale delta) / (accepted delta + rejected delta + stale delta) x 100

Here, a delta means the ending counter minus the starting counter. This formula is a worksheet, not a universal pool standard. Use the pool's own credited-share record for payment disputes, because the pool decides whether submitted work satisfies its rules.

Build a clean baseline before changing anything

Take one 15-minute sample while the miner is otherwise stable. Fifteen minutes is an editorial troubleshooting interval, not a claim that every pool or algorithm should be judged on that duration. Record longer pool-side trends as well: f2pool notes that pool and local hashrate can differ substantially over short periods and recommends comparing the 24-hour average when investigating that separate issue on its mining support page.

Use this worksheet for each controlled run:

Field	Run A	Run B	What must stay comparable
Start and end time in UTC	___	___	Same duration
Miner and worker name	___	___	Same machine and worker
Pool endpoint and region	___	___	Change only when testing the path
Accepted counter, start to end	___	___	Record the delta
Rejected counter, start to end	___	___	Record the delta and reason, if shown
Stale counter, start to end	___	___	Keep separate from other rejects
Firmware and tuning state	___	___	No silent update or profile change
Inlet temperature and fan state	___	___	Stay inside manufacturer requirements
Cable, switch port, and internet path	___	___	Note the one item changed

Save a screenshot or export from the pool for the same UTC window. A miner may reset local counters after a reboot, while the pool may continue aggregating the worker. Comparing unmatched start times can make a healthy change look like a fault.

Follow the symptom-to-cause decision tree

Use the first branch that matches the evidence. Do not replace hardware while the data still points to configuration or connectivity.

1. Are all configured pools shown as dead or disconnected? This is a connection problem before it is a share-quality problem. Verify the official endpoint, port, worker format, DNS reachability, Ethernet link, and firewall path with the pool settings guide.
2. Is the stale delta rising while other rejects stay flat? Test the nearest official regional endpoint, the local cable and switch port, and the upstream path. Braiins explains that stale or rejected work can arrive just after a block has been found and recommends a geographically close Stratum server in its guide to shares and pool hashrate.
3. Are non-stale rejects rising with a reason such as authorization or low difficulty? Recheck the exact account, worker, coin, port, and difficulty policy published by the pool. Do not assume that a live TCP connection proves the submitted share matches the pool's requirements.
4. Did the increase begin after a firmware or tuning change? Return to the last supported, known-good configuration and repeat the same window. Keep a copy of the current logs before rebooting or changing firmware.
5. Did the increase track heat, unstable hashrate, or missing chips? Restore the supported thermal and power conditions, then review the maintenance checklist. If the device reports a hardware fault, follow the manufacturer's repair guidance instead of repeatedly restarting it.
6. Do several miners on the same network rise together? Test the shared switch, router, internet service, and pool region before opening every miner. A simultaneous change across independent machines is stronger evidence of a shared path or pool-side event than of identical hardware failures.

The result of each branch should be a new measurement, not a conclusion based on one screenshot.

Test the network path without treating ping as proof

Network delay is a common cause, but one successful ping does not prove that Stratum job delivery and share submission are healthy over time. Use ping as a comparison between official endpoints, then confirm the effect with accepted, rejected, and stale deltas from the miner and pool.

Bitmain describes the path as three practical segments: the local network, the internet operator's network, and the pool server. Its miner FAQ identifies instability in any of those segments as a possible reason for a higher rejection rate. That division gives you a useful test order:

• Replace or reseat the local Ethernet cable and test a known-good switch port.
• Check whether other miners behind the same router changed at the same time.
• Compare the pool's official regional endpoints without changing the worker, firmware, or tuning profile.
• Review packet loss and latency over a sustained interval rather than trusting one minimum response.
• Ask the pool whether it recorded a regional endpoint incident during the exact UTC window.

The ASIC network reliability guide covers wired layout, failover, and monitoring in more depth. Bandwidth volume and share timing are different questions: a miner can use little data yet still have an unstable path.

Check configuration before blaming the pool

A miner can show a pool as alive while submitting work under the wrong account, through the wrong port, or under a rule the pool does not accept. Confirm the current endpoint directly from the operator, not from an old screenshot or marketplace listing. Verify the worker appears in the intended account and that its accepted counter moves.

Then read the pool's rejection reason, if available. A stale reason sends you back toward job timing and the network path. An authorization reason sends you to the worker format or account. A low-difficulty or invalid-work reason requires the pool's exact port and difficulty rules, plus a check of firmware and tuning. Preserve the original reason text in your worksheet; translating every error into "high rejects" discards the clue you need.

Do not change primary and failover pools together. Move one test worker to one official endpoint, hold every other variable constant, and compare a matching window. If the result improves, repeat once before moving the rest of the fleet.

Bring firmware, temperature, and hardware into the test carefully

Network problems are not the only possible source. Luxor's current mining reporting documentation tells operators to consider firmware condition, device-to-device variation, latency, and excessive temperature when investigating rejects. That is a cause checklist, not proof that any one factor explains your machine.

Use timing to narrow the list. If rejects rose immediately after a firmware or tuning change, restore the last supported configuration and remeasure. If they rise as inlet temperature or fan behavior changes, return the machine to the manufacturer's stated operating conditions before comparing. If one unit stays abnormal on a known-good cable, switch port, endpoint, firmware, and thermal setup while neighboring units remain stable, collect its logs and seek device-specific support.

Avoid unsupported flashes, aggressive tuning, or repeated power cycles as a first response. Those actions change several variables and can erase the clean before-and-after evidence that a pool or manufacturer needs.

Prepare an escalation packet instead of a vague complaint

If the controlled tests do not isolate the fault, send the pool or manufacturer a compact evidence packet:

• exact UTC start and end times;
• coin, endpoint, port, region, and anonymized worker identifier;
• accepted, rejected, and stale counter deltas from both interfaces;
• the exact rejection reason or relevant log lines;
• firmware version and whether tuning is enabled;
• inlet temperature, fan state, and any hardware warnings;
• the single change made between Run A and Run B;
• whether other miners on the same network showed the same pattern.

Redact passwords, payout credentials, session cookies, and private network details that support does not need. A precise window lets the pool examine its server records; a controlled comparison helps the manufacturer decide whether the evidence follows the device.

Open discussion: your normal baseline is local, not universal

Operators naturally want one percentage that separates normal from broken. The available documentation does not support a universal threshold across every coin, pool, endpoint, firmware build, share difficulty, and dashboard definition. Even the label "rejected" may combine different reasons, while stale work may be displayed separately.

A more durable standard is your own known-good baseline: the same machine, supported configuration, official endpoint, stable thermal conditions, and matching measurement window. Alert on a sustained departure from that baseline, then use the reason code and decision tree to choose the next test. Pools could make this easier by exposing consistent reason categories, timestamped counter resets, and exportable per-worker events. Until then, operators should preserve their own comparable records rather than borrowing a threshold from an unrelated setup.

Frequently asked questions

What rejection rate is too high for an ASIC miner?

There is no reliable universal cutoff for every pool, coin, firmware version, and dashboard definition. Establish a known-good baseline for the same miner and official endpoint, then investigate a sustained increase over comparable windows. Separate stale work from other rejects and read the pool's reason labels. A small short-lived change after a new block or reconnect is different from a persistent rise that tracks one endpoint, firmware change, temperature problem, or device.

Are stale shares and rejected shares the same thing?

Stale shares are a specific type of non-credited work submitted after the relevant job or block has changed. "Rejected" can be a broader label covering stale work or other reasons, depending on the interface. Keep stale and other rejected counters separate whenever both are available. Before combining them in a rate, confirm how the pool defines its dashboard metric and compare the same UTC window on the miner and pool.

Can high latency cause an ASIC miner to submit stale shares?

Yes. Delayed job updates or share submissions can leave a miner working on a job the pool no longer accepts. Test the closest official regional endpoint, a known-good Ethernet cable and switch port, and the shared upstream path. Do not rely on one ping result alone. Confirm improvement through accepted, rejected, and stale counter deltas over the same timed window, with firmware, tuning, and temperature held constant.

Should I switch pools when rejected shares increase?

Not immediately. First confirm the endpoint, worker format, port, rejection reason, and local network path. Then move one identifiable test worker to one official alternative endpoint while keeping every other variable fixed. Compare matching windows and repeat the result once. Switching an entire fleet at once can hide whether the cause was a cable, regional route, firmware change, thermal problem, account setting, or a temporary pool event.

Can firmware or overheating cause rejected shares?

They can contribute, but timing and controlled tests matter. If rejects rose after a firmware or tuning change, return to the last supported configuration and measure again. If the increase tracks inlet temperature, fan behavior, unstable hashrate, or hardware warnings, restore the manufacturer's operating conditions and inspect the logs. Do not use an unsupported flash or repeated reboots as the first test, because those actions change evidence and may add risk.

Why do the miner and pool show different share counts?

They may use different reset times, aggregation windows, delay periods, and definitions. A reboot can reset local counters while the pool keeps the worker's history. One interface may separate stale shares while the other combines them with rejects. Record starting and ending counters from both sides for the same UTC window, and use deltas rather than lifetime totals. For payment questions, the pool's credited-share record remains the relevant account evidence.

References

• Bitmain: Miner Status Page Explained
• f2pool: Mining support and rejection-rate guidance
• Braiins: Mining shares, stale work, and estimated hashrate
• Bitmain: FAQs for Miner
• Luxor: Mining reporting documentation