Learn what accepted, rejected, and stale mining shares mean, how PECPool uses valid shares to estimate hashrate and calculate PPS+ mining rewards, why shares may be rejected, and how to reduce stale or invalid submissions.
Accepted, rejected, and stale shares are important indicators of how effectively an ASIC miner is communicating with PECPool.
A miner can display normal local hashrate while still producing poor pool-side performance if too many of its submitted shares are rejected or arrive too late.
Understanding these values helps you evaluate:
This guide explains what mining shares are, how PECPool evaluates them, the difference between accepted, rejected, and stale shares, and how to reduce avoidable share loss.
A mining share is proof that an ASIC miner has completed a certain amount of mining work.
PECPool sends Bitcoin mining jobs to connected workers through the stratum protocol. The ASIC miner performs SHA-256 calculations and searches for results that meet the difficulty assigned by the pool.
When the miner finds a qualifying result, it submits that result to PECPool as a share.
The general process is:
Finding a complete Bitcoin block is rare, even for a large mining operation. A pool therefore needs a practical method to measure how much work each miner contributes between blocks.
Shares provide this measurement.
They allow PECPool to estimate:
PECPool uses the PPS+ payment method. Valid accepted shares are used to measure mining contribution and calculate the mining portion of rewards according to the pool's payment rules.
No. A normal mining share is not the same as a complete Bitcoin block.
A pool share usually meets a lower difficulty target assigned by the mining pool. It proves that the miner is performing real work, but it normally does not meet the much higher Bitcoin network difficulty required to create a block.
Occasionally, a submitted result may meet both:
In that case, the submitted work may become a valid Bitcoin block candidate.
Every valid block candidate is also a share, but almost every normal share is not a complete Bitcoin block.
An accepted share is a valid mining result that:
When PECPool accepts a share, it confirms that the pool received valid mining work from the worker.
Accepted shares are used to:
A steadily increasing accepted share count normally indicates that:
However, the raw number of accepted shares should not be compared directly between unrelated workers unless their assigned share difficulty and operating period are also considered.
A worker may submit fewer higher-difficulty shares while another worker submits more lower-difficulty shares. The number of shares alone does not always represent total hashrate.
A rejected share is a submitted mining result that PECPool cannot accept as valid mining credit.
Rejected shares may occur because:
Rejected shares normally do not contribute to effective mining rewards because the submitted work was not accepted by the pool.
A stale share is a share that may have been valid when the miner calculated it but arrived after the relevant mining job was no longer current.
This commonly happens when:
Because the share belongs to outdated work, it is classified as stale and is normally not credited as valid mining work.
A stale share is generally a specific type of rejected share.
The term rejected share describes the broader category of shares that were not accepted. The term stale share describes shares rejected specifically because they were associated with an outdated mining job or arrived too late.
| Share Type | Meaning | Normally Credited |
|---|---|---|
| Accepted | Valid share received and approved by PECPool | Yes |
| Rejected | Submitted share that did not pass pool validation | No |
| Stale | Share submitted for an outdated mining job | No |
The exact wording depends on the miner firmware and stratum implementation, but common rejection reasons include the following.
The submitted share belongs to a mining job that is no longer active.
Possible causes include:
The submitted result did not meet the share difficulty currently assigned to the worker.
Possible causes include:
The same mining result was submitted more than once.
Possible causes include:
The worker or account information was not accepted.
Possible causes include:
The recommended worker format is:
AccountName.WorkerNameExample:
myaccount.miner01The share failed technical validation.
Possible causes include:
The accepted and rejected share rates are commonly calculated from the total number of submitted shares.
Rejected share percentage:
Rejected Shares ÷ Total Submitted Shares × 100Example:
The rejected share rate is:
100 ÷ 10,000 × 100 = 1%Some miner interfaces may display stale shares separately, while others may include them inside the total rejected-share value.
The ideal rejected-share rate is as close to zero as reasonably possible.
A small number of occasional rejected or stale shares can occur even on a healthy mining connection because of normal internet delay, mining-job changes, and short connection events.
The important factor is whether the rate remains low and stable over time.
A consistently rising rejection rate or a sustained value around or above one percent should normally be investigated, especially when accompanied by:
There is no single universal percentage that applies equally to every network, firmware, miner model, and operating environment.
An ASIC miner consumes electricity while calculating every submitted share.
When a share is rejected, the electricity and computing effort used to calculate that specific result do not contribute to accepted pool work.
A high rejection rate can cause:
PECPool estimates worker hashrate from accepted mining shares received over time.
When accepted shares arrive consistently:
When accepted shares stop arriving, the displayed current hashrate will normally decrease and may eventually reach zero.
The miner's local interface measures internal hardware activity. PECPool measures effective work received through accepted shares.
A miner can therefore show normal local hashrate while producing lower pool-side hashrate because of:
For this reason, local hashrate should always be evaluated together with accepted shares, rejected shares, last-share time, and PECPool hashrate.
Latency is the time required for data to travel between the miner and the PECPool stratum server.
When a new job becomes available, a high-latency connection may delay:
The miner may continue working briefly on an older job and submit a result after the pool has already moved to the new job.
This increases the chance of stale shares.
The server with the lowest ping is not always the best server.
A connection with slightly higher latency but no packet loss may perform better than a lower-latency connection that frequently disconnects.
When comparing stratum servers, prioritize:
To reduce stale shares:
Check the following areas:
stratum+tcp:// address.When Pool 1 becomes unavailable, an ASIC miner may switch to Pool 2 or Pool 3.
A brief transition can create a small interruption while the miner:
Occasional failover is useful, but frequent switching usually indicates that the primary connection is unstable and should be investigated.
Most ASIC miners support three pool entries:
Configuring all three official PECPool addresses helps reduce complete mining downtime when:
Backup servers do not eliminate every rejected or stale share, but they can help keep the miner connected during a primary-path interruption.
When a miner restarts:
One or two rejected or stale shares may appear around a connection transition, but repeated restarts can produce continued instability and lower effective performance.
Depending on the ASIC manufacturer and firmware, share information may be visible under:
Common columns include:
The exact names depend on the miner model and firmware.
In the PECPool panel, review:
Share statistics are most useful when evaluated over a reasonable period rather than from only a few submissions.
Suppose a miner shows:
Total shares:
9,970 + 20 + 10 = 10,000Total rejected and stale percentage:
30 ÷ 10,000 × 100 = 0.3%If the worker remains stable, its hashrate is normal, and there are no repeated connection errors, this may represent normal low-level share loss.
Suppose a miner shows:
The large number of stale shares suggests that mining results are frequently arriving too late.
Investigate:
Suppose a miner shows:
This pattern is less likely to be caused only by network latency.
Investigate:
Further investigation is recommended when:
| Term | Meaning | Recommended Action |
|---|---|---|
| Accepted Share | Valid mining work approved by PECPool | No action required when increasing normally |
| Rejected Share | Submitted work that failed pool validation | Check the rejection reason |
| Stale Share | Valid-looking work submitted for an outdated job | Check latency, packet loss, and server selection |
| Low-Difficulty Share | Share did not meet the assigned pool difficulty | Check firmware and miner stability |
| Duplicate Share | The same share was submitted more than once | Check firmware, proxy, and connection behavior |
| Unauthorized Worker | The account or worker information was not accepted | Correct the worker configuration |
Accepted shares represent useful mining work successfully received by PECPool. Rejected and stale shares represent work that could not be credited.
A small number of occasional rejected shares can be normal, but a persistent increase should be investigated because it can reduce effective pool-side hashrate and mining efficiency.
For the best results, use a stable regional PECPool stratum server, configure reliable backup pools, maintain a stable wired network, use trusted firmware, and review share statistics together with hashrate and worker status.
Copyright ©2026 PECPool.