Rejected or stale shares mean your miner is submitting work that the pool does not accept. A small number of rejected or stale shares can be normal, but frequent rejected or stale shares usually indicate a problem with the rig, miner configuration, pool connection, network path, or hardware stability.

For rig owners, rejected and stale shares matter because renters are paying for usable mining work. A rig may show hashrate in the miner console, but if the submitted shares are rejected or stale, the renter may not receive the expected pool-side performance.

Troubleshooting Rejected or Stale Shares

Mining pools accept shares as proof that your miner is working correctly. When a share is rejected, the pool received the share but did not accept it. When a share is stale, the share was submitted too late for the current mining job.

Some rejected or stale shares can happen during normal mining. However, a high reject or stale rate can reduce the effective hashrate delivered to the renter.

Rejected shares vs stale shares

Rejected and stale shares are related, but they are not always caused by the same issue.

Different pools and miners may use different wording, but the result is the same: the share did not count as accepted mining work.

What reject or stale rate is acceptable?

There is no single perfect number for every algorithm, miner, or pool.

In general:

• 0% is ideal, but not always realistic.
• Very low reject/stale rates may be normal.
• Consistent or rising reject/stale rates should be investigated.
• High reject/stale rates usually indicate a real problem.

If renters are seeing poor pool-side performance, frequent disconnects, or unstable hashrate, rejected and stale shares should be one of the first things you check.

Common causes of rejected shares

1. Overclock or undervolt instability

Unstable hardware tuning is one of the most common causes of rejected shares.

A miner may appear to run normally while still producing bad shares. This often happens when memory clocks, core clocks, voltage, or power limits are too aggressive.

Common signs include:

• rejected shares increase over time,
• one GPU or ASIC board rejects more shares than others,
• miner logs show hardware errors,
• hashrate looks high but accepted shares are lower than expected,
• the rig becomes unstable during rentals but not during short tests.

Recommended fix:

Lower the overclock, increase stability margin, or return the device to stock settings for testing. A slightly lower stable hashrate is better than a higher unstable hashrate that produces rejected shares.

2. Wrong algorithm or coin configuration

Rejected shares can happen if the miner is configured for the wrong algorithm, wrong coin variant, or wrong mining mode.

This is especially important for algorithms with similar names or multiple variants.

Recommended fix:

Verify that:

• the rig is listed under the correct algorithm,
• the miner is using the correct algorithm parameter,
• the renter’s pool supports the same algorithm,
• the pool URL and port match the intended coin/algorithm,
• any required extra miner options are correct.

Do not assume two algorithms are compatible because they have similar names.

3. Incorrect wallet, worker, or pool parameters

Some pools reject shares when the username, wallet address, worker name, password field, or extra parameters are incorrect.

Recommended fix:

Check the pool’s required connection format. Some pools require:

• wallet.worker,
• username.worker,
• a specific password value,
• a coin symbol in the password field,
• a mining mode parameter,
• a fixed difficulty prefix,
• TLS or non-TLS port selection.

If the miner connects but shares are rejected, review the pool’s exact stratum instructions.

4. Pool difficulty problems

If share difficulty is too low, the miner may submit excessive shares. If it is too high, reporting can become unstable and shares may be submitted less frequently.

Some pools use variable difficulty, also called VarDiff, and automatically adjust difficulty after the miner connects. Other pools allow or require fixed difficulty.

Recommended fix:

Let the miner run long enough for pool difficulty to stabilize. If using fixed difficulty, confirm that the value is appropriate for the rig’s hashrate.

Do not confuse share difficulty with network difficulty. Network difficulty is controlled by the blockchain. Share difficulty is controlled by the pool or mining connection.

5. Miner software bugs or unsupported versions

Miner software can cause rejected, duplicate, or invalid shares if it has a bug, does not properly support the algorithm, or is outdated.

Recommended fix:

Try a known stable miner version for the algorithm. If the problem started after a miner update, test the previous version. If the problem occurs only with one miner program, test another miner that supports the same algorithm.

Also check whether the miner has special requirements for:

• GPU driver version,
• CUDA version,
• OpenCL runtime,
• ASIC firmware,
• algorithm-specific flags,
• extranonce support,
• stratum protocol version.

6. Hardware errors

Faulty GPUs, ASIC hashboards, risers, power supplies, memory, or unstable PCIe connections can cause rejected shares.

Recommended fix:

Check miner logs and hardware monitoring for:

• hardware errors,
• CRC errors,
• ASIC chip errors,
• GPU memory errors,
• thermal throttling,
• device resets,
• watchdog restarts,
• disappearing devices.

If one device is responsible for most of the rejected shares, remove it from the rig or reduce its clocks until it is stable.

Common causes of stale shares

1. Network latency

Stale shares often happen when the miner receives new work too late or submits completed work too slowly.

Common causes include:

• high latency to the renter’s pool,
• congested internet connection,
• packet loss,
• unstable Wi-Fi,
• overloaded router,
• poor routing between regions,
• VPN or proxy latency,
• pool server located far away.

Recommended fix:

Use a stable wired connection when possible. Avoid Wi-Fi for production mining rigs. Check latency and packet loss to common pool regions. If stale shares only happen with pools in distant regions, the issue may be network distance rather than rig hardware.

2. Pool server instability

Sometimes stale shares are caused by the pool, not the rig.

Pool-side problems can include:

• overloaded stratum servers,
• frequent job changes,
• poor regional routing,
• unstable pool backend,
• slow block template updates,
• temporary outages.

Recommended fix:

Test against a known stable pool for the same algorithm. If stale shares disappear on another pool, the original pool may be the cause.

3. Miner connection interruptions

If the miner frequently disconnects and reconnects, it may submit stale or duplicate shares around reconnection events.

Recommended fix:

Review the miner logs for:

• reconnect loops,
• authorization failures,
• socket errors,
• connection timeouts,
• DNS failures,
• stratum interruptions,
• watchdog restarts.

Fix the connection issue before increasing advertised hashrate or relisting the rig.

4. Excessive system load

A mining rig with high CPU load, unstable drivers, insufficient memory, disk issues, or overloaded management software may respond slowly to new mining jobs.

Recommended fix:

Check system health:

• CPU usage,
• memory usage,
• disk errors,
• driver crashes,
• OS logs,
• miner watchdog logs,
• background processes,
• remote management tools.

Mining rigs should not be overloaded with unnecessary services while rented.

How to troubleshoot step by step

Step 1: Check the miner logs

Start with the miner log. Look for:

• rejected shares,
• stale shares,
• invalid shares,
• duplicate shares,
• hardware errors,
• reconnects,
• authorization failures,
• difficulty changes,
• pool disconnects.

The miner log usually gives the first clue about whether the problem is hardware, pool, network, or configuration related.

Step 2: Compare accepted shares against reported hashrate

A miner may show strong local hashrate while still producing rejected shares. Local hashrate is not enough by itself.

Check:

• accepted share count,
• rejected share count,
• stale share count,
• pool-side hashrate,
• Mining Rig Rentals reported hashrate,
• individual worker performance.

The important question is not only “is the miner hashing?” but “is the pool accepting the work?”

Step 3: Test with a known-good pool

Use a pool you know works correctly for the same algorithm.

If shares are accepted normally on the test pool, the issue may be related to the renter’s pool, pool region, pool difficulty, or pool connection format.

If rejected or stale shares continue on multiple pools, the issue is more likely with the rig, miner, network, or hardware.

Step 4: Reduce overclocks and retest

If rejected shares are present and the cause is not obvious, reduce clocks and retest.

Recommended testing approach:

1. Lower memory clocks.
2. Lower core clocks if needed.
3. Increase voltage or reduce undervolt if needed.
4. Reduce power limit aggressiveness.
5. Restart the miner.
6. Test long enough to confirm accepted shares remain stable.

Do not judge stability from only a few minutes of mining. Some instability appears only after the rig warms up or after a rental has been running for a while.

Step 5: Check network quality

For stale shares, test network health.

Check for:

• packet loss,
• high latency,
• jitter,
• DNS failures,
• router overload,
• ISP instability,
• VPN or tunnel issues,
• unstable wireless links.

Even if the rig’s hashrate is correct, bad network conditions can cause stale shares and poor pool-side results.

Step 6: Check each worker separately

If the rig has multiple workers, one unstable worker can hurt the entire listing.

Review each worker for:

• accepted share rate,
• rejected share rate,
• stale share rate,
• connection stability,
• hashrate consistency,
• hardware errors.

Remove or fix unstable workers before advertising the rig as available.

When the renter’s pool may be the issue

Sometimes rejected or stale shares are caused by the renter’s pool configuration or pool infrastructure.

Possible renter-side or pool-side causes include:

• wrong pool URL,
• wrong port,
• wrong algorithm,
• unsupported coin variant,
• incorrect wallet format,
• incorrect password parameters,
• pool server outage,
• pool region too far from the rig,
• pool requiring special miner options,
• pool using unusual stratum behavior.

However, rig owners should still verify that their rig works correctly through Mining Rig Rentals on a known-good pool. A rig should be stable before being listed for rent.

Best practices to prevent rejected or stale shares

Before listing your rig:

• test through Mining Rig Rentals,
• use stable clocks instead of maximum clocks,
• confirm the algorithm is correct,
• test with a known-good pool,
• monitor accepted and rejected shares,
• use a stable wired internet connection,
• avoid unstable VPN or proxy routing,
• keep miner software and drivers at stable versions,
• check each worker individually,
• set an accurate advertised hashrate,
• use an appropriate suggested share difficulty.

A rig that is stable before rental is less likely to create renter complaints or refund disputes.

When to lower your advertised hashrate

If reducing clocks fixes rejected shares, update your advertised hashrate to match the new stable performance.

Do not keep advertising the old hashrate if the rig can only reach it with unstable settings.

A lower stable hashrate is better than a higher unstable hashrate that produces rejected shares, stale shares, or disconnects during rentals.

When to contact support

Contact Mining Rig Rentals support if:

• the rig works on direct pool connection but fails through Mining Rig Rentals,
• rejected or stale shares appear only when routed through Mining Rig Rentals,
• worker data does not match miner or pool behavior,
• you believe there is a platform-side routing or reporting issue,
• a rental dispute requires review.

When contacting support, include:

• rig name or ID,
• rental ID if applicable,
• algorithm,
• miner software and version,
• pool URL and port,
• screenshots or logs showing rejected/stale shares,
• approximate time the issue occurred,
• whether the problem happens on multiple pools.

Clear logs and exact times help support review the issue faster.

Summary

Rejected and stale shares reduce the amount of useful mining work delivered to the renter.

Most issues come from one of the following:

• unstable overclocking,
• wrong algorithm or pool settings,
• hardware errors,
• miner software problems,
• bad network conditions,
• pool-side instability,
• difficulty mismatch.

The best fix is to test the rig through Mining Rig Rentals, verify accepted shares on a known-good pool, tune for stability, and advertise only the hashrate the rig can reliably deliver.