How to Fix High Rejected Share Rate

Learn why an ASIC miner may submit too many rejected or stale shares to PECPool and how to fix the problem. This guide covers stratum server selection, network latency, packet loss, worker configuration, firmware, overclocking, hardware errors, mining proxies, and practical troubleshooting steps.

A high rejected-share rate means that part of the mining work submitted by your ASIC miner is not being accepted as valid contribution by PECPool.

A small number of occasional rejected or stale shares can occur during normal mining. However, a consistently elevated rejection rate can reduce effective pool-side hashrate, waste electricity, and lower mining efficiency.

The miner may still display normal local hashrate while PECPool receives less useful mining work because part of the submitted shares are rejected.

This guide explains the most common rejected-share types, how to identify the cause, and how to reduce the rejected-share rate on Antminer, WhatsMiner, and other compatible Bitcoin SHA-256 ASIC miners.

What Is a Rejected Share?

A mining share is proof that an ASIC miner has completed a certain amount of mining work. The miner submits the share to PECPool through the stratum connection.

PECPool validates every submitted share. A valid share is classified as Accepted. A share that does not pass validation is classified as Rejected.

The general process is:

1. PECPool sends a mining job to the worker.
2. The ASIC miner performs SHA-256 calculations.
3. The miner finds a result that meets the assigned share difficulty.
4. The miner submits the result to PECPool.
5. PECPool validates the account, worker, job, difficulty, and share data.
6. The share is classified as Accepted or Rejected.

Why Rejected Shares Matter

ASIC miners consume electricity while calculating every submitted share.

When a share is rejected, the electricity and mining work used to calculate that result do not contribute to accepted pool work.

A high rejected-share rate can cause:

• Lower effective pool-side hashrate
• Reduced accepted mining contribution
• Lower mining efficiency
• More wasted electricity
• Unstable worker statistics
• A larger difference between local and pool hashrate

Accepted, Rejected, and Stale Shares

Share Type	Meaning	Normally Credited
Accepted	Valid mining work received and approved by PECPool	Yes
Rejected	Submitted mining work that failed pool validation	No
Stale	A share submitted for an outdated mining job	No

A stale share is generally a specific type of rejected share. Some miner interfaces display stale shares separately, while others include them in the total rejected-share count.

How to Calculate the Rejected-Share Rate

The rejected-share percentage can be calculated as follows:

Rejected Share Rate =
Rejected Shares ÷ Total Submitted Shares × 100

Example:

• Accepted shares: 9,900
• Rejected shares: 100
• Total submitted shares: 10,000

The rejected-share rate is:

100 ÷ 10,000 × 100 = 1%

If stale shares are displayed separately, you may also calculate the combined unsuccessful share rate:

Combined Unsuccessful Rate =
Rejected Shares + Stale Shares
÷ Total Submitted Shares
× 100

What Is a Normal Rejected-Share Rate?

The ideal rejected-share rate is as close to zero as reasonably possible.

A small number of occasional rejected or stale shares may occur because of normal internet delay, mining-job changes, short network interruptions, or pool failover.

The important point is whether the rate remains low and stable over time.

Further investigation is recommended when:

• The rejected percentage continuously increases.
• The rate remains noticeably higher than similar miners on the same network.
• Pool-side hashrate is significantly lower than expected.
• The worker frequently disconnects or switches pools.
• Large gaps appear in the hashrate chart.
• The miner log repeatedly reports rejection errors.

There is no single percentage that applies equally to every miner, network, firmware, share difficulty, and operating environment.

Identify the Rejection Reason First

Do not change random miner settings before checking the exact rejection reason.

Open the miner's local management interface and review:

• Miner Status
• Pool Status
• CGMiner Status
• System Log
• Kernel Log
• Event Log

Common rejection messages include:

• Stale
• Job Not Found
• Low Difficulty Share
• Duplicate Share
• Unauthorized Worker
• Invalid Share
• Invalid Nonce
• Unknown Job

The correct solution depends on the rejection type.

Stale or Job Not Found

A stale share belongs to a mining job that is no longer current.

The normal sequence is:

1. PECPool sends a mining job to the miner.
2. The miner begins calculating results for that job.
3. A new Bitcoin block or updated job becomes available.
4. The old job becomes obsolete.
5. The miner submits a result for the old job too late.

Common causes include:

• High network latency
• Packet loss
• Unstable internet connectivity
• A distant or unstable stratum server
• Frequent pool reconnections
• Slow or overloaded network equipment
• Unstable mining proxy operation

How to Reduce Stale Shares

• Use the most stable PECPool regional server.
• Test another official PECPool port.
• Use a wired Ethernet connection.
• Replace damaged Ethernet cables.
• Check switches and routers for packet loss.
• Avoid unstable Wi-Fi or wireless bridges.
• Reduce unnecessary network congestion.
• Check mining proxies for delays or overload.
• Avoid frequent miner restarts.
• Configure reliable backup pool addresses.

Choose the Correct PECPool Stratum Server

The nearest server is a useful starting point, but the most geographically nearby server is not always the most stable.

Internet routing, packet loss, ISP filtering, and network congestion can make a more distant server perform better.

Official PECPool Bitcoin stratum servers include:

Region	Server	Available Ports
Global	btc.pecpool.com	3333, 443, 25
United States	btc-us.pecpool.com	3333, 443, 25
Europe	btc-eu.pecpool.com	3333, 443, 25
Russia	btc-ru.pecpool.com	3333, 443, 25
Asia	btc-as.pecpool.com	8443, 443, 25
Iran	btc-ir.pecpool.com	8443, 443, 25
Iran Alternative	btc.pecpool.cc	8443, 443, 25

After changing the server, allow the miner to operate for a reasonable period before comparing the result.

Configure Pool 1, Pool 2, and Pool 3

Most ASIC miners support three pool entries.

A diversified configuration can reduce complete downtime:

Pool 1

URL: stratum+tcp://btc-eu.pecpool.com:3333
Worker: myaccount.miner01
Password: x

Pool 2

URL: stratum+tcp://btc.pecpool.com:443
Worker: myaccount.miner01
Password: x

Pool 3

URL: stratum+tcp://btc-us.pecpool.com:25
Worker: myaccount.miner01
Password: x

The same mining account and worker name should normally be used in all three entries of the same physical miner.

Test Network Latency

Latency is the time required for data to travel between the miner and the PECPool stratum server.

From Windows:

ping btc-eu.pecpool.com

From Linux:

ping -c 20 btc-eu.pecpool.com

Ping can show approximate delay and obvious packet loss, but it should not be used as the only mining test.

Some servers may ignore Ping while still accepting stratum connections.

Test the Stratum Port

From Windows PowerShell:

Test-NetConnection btc-eu.pecpool.com -Port 3333

Look for:

TcpTestSucceeded : True

From Linux:

nc -vz btc-eu.pecpool.com 3333

If one port is unavailable, test another official port for the same server.

Check Packet Loss

Packet loss can cause delayed jobs, missing submissions, connection resets, and stale shares.

Possible signs include:

• Intermittent Ping timeouts
• Large variations in latency
• Frequent stratum reconnects
• Repeated Pool Dead messages
• Gaps in the worker hashrate chart
• Stale shares increasing during specific hours

Check:

• Ethernet cables
• Network switch ports
• Router performance
• Wireless links
• ISP stability
• Network congestion

Lower Latency Does Not Always Mean Better Performance

Consider the following example:

Server A

Average Latency: 40 ms
Packet Loss: 3%
Frequent Disconnects: Yes

Server B

Average Latency: 80 ms
Packet Loss: 0%
Frequent Disconnects: No

Server B may produce fewer stale and rejected shares because the connection is more stable, even though its latency is higher.

Prioritize:

1. Stable connectivity
2. Low packet loss
3. Consistent accepted shares
4. Low stale-share rate
5. Low latency

Low-Difficulty Shares

A low-difficulty share does not meet the share difficulty currently assigned to the worker.

Possible causes include:

• Miner firmware problems
• Custom firmware incompatibility
• Incorrect difficulty handling
• Corrupted mining data
• Unstable overclocking
• Mining proxy errors

Low-difficulty rejects are normally not solved by changing only the regional server. Review the miner firmware, performance settings, and proxy configuration.

Duplicate Shares

A duplicate share means the same mining result was submitted more than once.

Possible causes include:

• Firmware bugs
• Mining proxy problems
• Repeated share transmission after network interruptions
• Incorrect mining software implementation
• Unstable control-board operation

Recommended actions:

1. Review the miner log.
2. Restart the mining process once.
3. Check the firmware version.
4. Temporarily bypass the mining proxy when possible.
5. Compare the result using a direct PECPool connection.

Unauthorized Worker

An authorization rejection means the miner reached the server, but the account or worker information was not accepted correctly.

The recommended worker format is:

AccountName.WorkerName

Example:

myaccount.miner01

Check for:

• Incorrect mining account name
• Missing account name
• Missing dot separator
• Spaces in the Worker field
• Unsupported characters
• Email address entered as worker
• Wallet address entered as worker

Check the Pool Password

The Pool Password field is not your PECPool login password.

When no special stratum password is required, enter:

x

Never enter:

• Your PECPool login password
• Your email password
• Your Two-Factor Authentication code
• Your API Secret
• Your Bitcoin private key
• Your wallet seed phrase

Invalid Shares and Hardware Errors

Invalid shares can be caused by incorrect ASIC calculations or corrupted work.

Check:

• Hardware error count
• ASIC chip status
• Hashboard detection
• Miner temperature
• Fan or cooling-system operation
• Power supply stability
• Frequency and voltage settings

A high hardware-error rate can increase invalid results even when local hashrate appears normal.

Check Miner Temperature

Excessive temperature can make ASIC chips unstable and increase hardware or invalid-share errors.

Check that:

• Air intake is not blocked.
• Hot exhaust air does not return to the intake.
• Fans are operating normally.
• Heat sinks and air channels are clean.
• The mining room has sufficient ventilation.
• Hydro-cooling or immersion systems operate correctly when applicable.

Compare the miner's temperature with the normal range specified for the exact model.

Check the Power Supply

Unstable power can cause chip errors, hashboard resets, and repeated miner restarts.

Check:

• Input voltage
• Power supply capacity
• Power connectors
• Electrical cable condition
• Voltage drops under load
• Power distribution equipment

Do not continue operating a miner with loose, damaged, overheated, or discolored power connections.

Overclocking and Rejected Shares

Increasing frequency can raise local hashrate, but aggressive overclocking may also increase:

• Hardware errors
• Invalid shares
• Miner restarts
• Temperature
• Power consumption
• Hashboard instability

A miner with higher local hashrate but many rejected shares may produce less effective pool-side performance than a miner operating at stable settings.

If rejected shares increased after overclocking:

1. Return the miner to the previous stable profile.
2. Allow it to run for a reasonable period.
3. Compare accepted and rejected shares.
4. Compare the 1-hour and 24-hour PECPool hashrate.

Undervolting and Insufficient Voltage

Undervolting can reduce power consumption, but insufficient voltage may cause ASIC calculation errors and unstable hashboards.

If low-difficulty or invalid shares increase after changing voltage settings, return to a stable configuration and test again.

Firmware Problems

Firmware controls mining jobs, ASIC operation, pool communication, and share submission.

Firmware-related problems may cause:

• Duplicate shares
• Low-difficulty shares
• Incorrect nonce submissions
• Pool disconnections
• Unstable performance

Recommended actions:

• Use trusted firmware.
• Confirm compatibility with the exact miner model.
• Review firmware release notes.
• Avoid unknown modified firmware.
• Back up important settings before upgrading.
• Do not interrupt power during firmware installation.

Check Mining Proxy Performance

Mining proxies can centralize connections for many miners, but an overloaded or unstable proxy can create:

• Share-submission delays
• Stale shares
• Duplicate shares
• Frequent reconnections
• Large groups of workers going Offline together

Check:

• Proxy CPU and memory usage
• Proxy network capacity
• Connection count
• System logs
• Latency between miners and proxy
• Latency between proxy and PECPool

When practical, connect one affected miner directly to PECPool temporarily. If the rejected-share rate improves, investigate the proxy or the network path to it.

Check the Miner Date and Time

Incorrect system time may affect logging, diagnostics, or secure functions in some firmware versions.

Configure automatic time synchronization when supported and verify the correct gateway and DNS configuration.

Frequent Pool Switching

If the miner repeatedly switches between Pool 1, Pool 2, and Pool 3, stale or rejected shares may increase during each transition.

Check:

• Pool 1 connectivity
• Router and ISP stability
• DNS resolution
• Firewall rules
• Miner logs
• Selected regional server

If Pool 2 consistently performs better, move that server to Pool 1 after sufficient testing.

Rejected Shares Increased After Changing the Server

If rejected or stale shares increased after changing the PECPool server:

1. Confirm the new server and port are entered correctly.
2. Check latency and packet loss.
3. Review the miner log.
4. Allow enough time for a meaningful comparison.
5. Return to the previous stable server when necessary.

Do not judge the result from only a small number of shares.

Only One Miner Has a High Rejected Rate

If other miners on the same network operate normally, the problem is more likely related to the affected miner.

Check:

• Its Ethernet cable
• Its switch port
• Its firmware
• Its overclocking profile
• Its temperature
• Its hashboards
• Its miner logs

All Miners Have a High Rejected Rate

If many workers begin showing high rejected or stale shares at the same time, investigate shared infrastructure:

• Internet connection
• Main router or gateway
• Network switches
• DNS service
• ISP routing
• Mining proxy
• Shared PECPool stratum server

Compare the exact time when rejection rates increased across all workers.

Compare Local and Pool-Side Hashrate

A large difference between local and PECPool hashrate may indicate that useful mining work is being lost.

Review:

• Current hashrate
• 1-hour hashrate
• 24-hour hashrate
• Accepted shares
• Rejected shares
• Stale shares
• Last-share time

Use the longer PECPool averages for a more reliable comparison.

Example 1: High Stale-Share Rate

Miner statistics:

Accepted Shares: 9,200
Rejected Shares: 100
Stale Shares: 700

The high stale-share count suggests that mining results are frequently arriving after the job has changed.

Investigate:

• Network latency
• Packet loss
• Stratum server selection
• Router and switch performance
• Mining proxy delays

Example 2: High Invalid-Share Rate

Miner statistics:

Accepted Shares: 8,000
Invalid Shares: 1,800
Stale Shares: 200

The rejection pattern is more likely related to firmware, hardware errors, voltage, frequency, or hashboard instability than only network latency.

Example 3: Rejections After Overclocking

Before overclocking:

Local Hashrate: 100 TH/s
Rejected Rate: 0.3%

After overclocking:

Local Hashrate: 112 TH/s
Rejected Rate: 5.5%
Frequent Miner Restarts: Yes

Although local hashrate increased, the miner became unstable. Returning to the previous stable configuration may produce better effective pool-side performance.

Recommended Troubleshooting Order

1. Record the current accepted, rejected, and stale counts.
2. Review the exact rejection reason in the miner log.
3. Confirm the Pool URL, port, worker, and password.
4. Check whether one miner or all miners are affected.
5. Test network latency and packet loss.
6. Test another official PECPool server or port.
7. Inspect Ethernet cables, switches, and routers.
8. Check mining proxy performance.
9. Review miner temperature and hardware errors.
10. Return overclocking or undervolting to stable settings.
11. Review firmware compatibility.
12. Monitor the result over a reasonable period.

Do Not Change Multiple Settings at Once

Changing the server, firmware, frequency, voltage, network equipment, and proxy configuration at the same time makes it difficult to identify the real cause.

Use a controlled process:

1. Record the current statistics.
2. Change one setting.
3. Allow enough time for new shares to be submitted.
4. Compare the result.
5. Keep or reverse the change.

How Long Should You Test a Change?

A very short test may be misleading because share submission is naturally variable.

For an initial check, observe the miner long enough to confirm:

• The connection remains active.
• Accepted shares continue increasing.
• The same rejection reason does not continue.

For a more reliable comparison, monitor the miner for several hours and review longer hashrate averages.

Common Mistakes

• Assuming every rejected share is caused by the pool
• Ignoring the rejection reason in the miner log
• Selecting a server only from one Ping result
• Ignoring packet loss
• Using unstable custom firmware
• Using aggressive overclocking settings
• Using Wi-Fi for ASIC mining
• Ignoring mining proxy performance
• Changing many settings simultaneously
• Judging results immediately after a miner restart

Quick Reference

Rejection Type	Likely Cause	Primary Check
Stale	Latency, packet loss, outdated job	Network and server selection
Job Not Found	Old job or delayed submission	Connectivity and proxy
Low Difficulty	Firmware or unstable mining settings	Firmware, voltage, and frequency
Duplicate Share	Firmware, proxy, or repeated transmission	Miner and proxy logs
Unauthorized	Incorrect account or worker	Worker configuration
Invalid Share	Hardware or calculation errors	Hashboards, temperature, and power

Final Checklist

• The miner uses an official PECPool stratum server.
• The selected port is reachable and stable.
• The worker uses AccountName.WorkerName format.
• The Pool Password is x.
• Accepted shares are increasing.
• The exact rejection reason has been reviewed.
• Packet loss is not present.
• The miner uses a wired Ethernet connection.
• Pool 1, Pool 2, and Pool 3 are configured.
• The miner does not repeatedly switch pools.
• Firmware is trusted and compatible.
• Overclocking and voltage settings are stable.
• Temperature and cooling are normal.
• Hardware errors are not unusually high.
• The mining proxy is not overloaded.

Focus on Effective Hashrate

The goal is not only to produce a high local hashrate number. The goal is to submit as much valid mining work as possible to PECPool.

A miner with slightly lower local hashrate and a low rejected-share rate may produce better effective results than an unstable miner with higher local hashrate and many rejected shares.

Start by identifying the rejection type, then check the network, stratum server, worker configuration, firmware, mining settings, temperature, power, and hardware condition in a controlled order.