APP
How to Reduce Stale Shares With Better Pool URL and Network Routing
2026-09-06 22:22

A stale share is an otherwise valid share submitted for a mining job the pool no longer accepts, commonly after a new block causes the previous job to be superseded before the miner's work reaches the pool. Because pooled mining depends on a continuous flow of jobs and share submissions between the ASIC and the pool server, the connection path between them—the pool URL, the routing to that endpoint, and the stability of the session—can affect how often latency-related stale shares occur. This article explains what stale shares are, why endpoint selection and network routing matter, and how to test and validate connection changes using pool-side rejection data.

What Counts as a Stale Share

Rejected shares are the broader category of submitted shares that a pool does not credit, although dashboards and miner firmware may display stale shares separately. A stale share is one specific rejection type: the miner submitted proof-of-work that was valid for an earlier job, but the pool had already replaced that job before the submission arrived. Other rejection reasons—such as duplicate or invalid shares—are separate and should not be conflated with staleness when reviewing pool or miner data. In Stratum-based pooled mining, pools distribute jobs and can instruct connected miners to discard outdated work; shares submitted after the relevant job is no longer accepted may be classified as stale (PoPETS 2017).

Pool share targets are typically numerically higher, and therefore easier to satisfy, than the Bitcoin network's block target. This allows a pool to receive frequent share submissions as evidence of contributed work rather than waiting for an actual block solution from each miner (Bitcoin Developer Guide: Mining). The share target itself is not the source of staleness; timing and job validity are.

Why the Pool URL and Connection Path Matter

The Stratum endpoint a miner connects to is not simply a login destination. It is the channel used to receive new jobs, receive job updates when the chain tip changes, and submit shares back to the pool. When a new block is detected, the pool distributes updated work reflecting the new previous-block hash. Additional delay between that update and the ASIC beginning valid new work can extend the period in which the miner is still hashing an obsolete job. Delay on the return path can also cause an otherwise valid share to arrive after the relevant job is no longer accepted.

This framing explains why endpoint accuracy and routing quality are relevant to stale-share outcomes without implying that connectivity is the only variable. Firmware job-handling behavior, pool-side job update and distribution timing, packet loss, and unstable sessions can also contribute. Network latency should therefore be treated as one diagnostic factor rather than converted directly into an expected stale-share percentage.

Step 1: Confirm the Current Official Endpoint

Before investigating routing quality, first rule out an outdated, incorrect, or unofficial pool URL. Configuration values can change, and endpoints for one coin or mining mode are not interchangeable with another.

Before testing the route, confirm:

  • the protocol prefix, hostname, and port match the pool's current documentation for the specific coin;
  • the endpoint matches the intended mining mode. ViaBTC's BTC Mining guide distinguishes standard BTC mining URLs from Smart Mining URLs. A URL for a different mining mode may still establish a connection, but the miner may operate under a different mode than intended;
  • the worker name format matches what the pool expects.

ViaBTC's Mining Pools Information page is maintained as a current directory of global and regional connection details, including failover ports. Because these values can be updated, screenshots, forum posts, or previously saved configuration files should not be treated as permanently correct. ViaBTC has separately advised miners to use only official pool URLs and the official mining agent, noting that unofficial sources can introduce connection risks and affect hashrate stability and mining earnings (official URL notice). An unofficial or unverified intermediary also introduces a connection path the pool operator does not control.

Step 2: Use a Documented Regional Endpoint Where Available

Where a pool documents more than one regional connection option, selecting the one closer to the mining location is a reasonable starting point, but geographic proximity alone does not guarantee the best network path. Hosting infrastructure and internet routing can cause two geographically similar endpoints to behave differently from a particular mining site.

A practical approach is to test the documented endpoints available for the mining location while keeping every other variable—firmware, worker configuration, and network hardware—unchanged, then compare the results rather than assuming which option is faster.

Step 3: Test the Stratum Connection, Not Just Ping

Standard ICMP ping can surface obvious network failures and provide a basic latency signal, but it does not exercise the Stratum session itself. It may therefore miss problems that appear only when the miner establishes and maintains the actual mining connection.

Where suitable diagnostic tooling is available, a TCP or application-level Stratum test can provide more relevant information by exercising the connection to the mining port and, in some cases, the protocol or authentication exchange. Even then, one test reflects only a short sample of the path. It does not capture every job update, packet-loss event, or reconnection a miner may experience over hours of operation. Use connection tests as diagnostic signals, then confirm whether a change actually helped using pool-side rejection data.

Step 4: Remove Avoidable Delay Inside the Local Network

Before attributing stale shares to the pool's infrastructure, review conditions inside the mining operation's own network, since these are often directly controllable. Practical checks include using wired connectivity for ASICs where possible, reviewing recurring reconnects or DNS failures, and checking whether a router or switch is dropping packets or becoming overloaded.

It is also worth avoiding an unverified proxy or VPN added solely to change the apparent network location, since it introduces another hop and another potential failure point. If a proxy is used deliberately—for example, to aggregate multiple miners—test the full miner-to-pool path afterward rather than assuming that the proxy improves routing by default.

Keeping a documented primary endpoint and a documented backup endpoint configured allows firmware to fail over according to its own reconnection logic if the primary path becomes unreachable, rather than leaving the miner offline until the configuration is manually corrected.

Step 5: Validate Changes With Pool-Side Data

Any routing or endpoint change should be validated with data rather than assumed to have worked. A defensible sequence is:

  1. Record the currently configured endpoint, port, firmware version, and the time the test period begins.
  2. Review miner logs for reconnect events, connection errors, and rejection messages.
  3. Review the pool dashboard's rejection breakdown, separating stale rejections from other reasons where that detail is available.
  4. Change one variable at a time—for example, only the regional endpoint or only a local network fix—rather than multiple variables together.
  5. Compare periods with similar uptime and operating conditions, since a period with frequent restarts is not comparable to a stable one.

Avoid comparing raw share counts across different variable-difficulty settings. Also avoid treating miner-reported hashrate and pool-estimated hashrate as interchangeable readings when assessing whether a change helped; they are related but measured differently.

A Note on Stratum V2

The Stratum V2 Mining Protocol defines channels between mining devices and upstream Stratum nodes, which may be pools or proxies, and uses shared broadcast messages for events such as a new previous-block hash. Its specification notes that proxies can aggregate mining channels into fewer connections, reducing the number of broadcast messages and network traffic, which can lower latency (Stratum V2 Mining Protocol specification).

This is useful context for operators evaluating future infrastructure, but practical use depends on support across the pool, proxy, and mining-device or firmware stack. It should not be treated as a substitute for correct endpoint selection, stable routing, and sound local network practice.

FAQ

What is the difference between a stale share and a rejected share?

A rejected share is submitted work that the pool does not credit. A stale share is one possible rejection reason: the work was valid for an earlier job but reached the pool after that job was no longer accepted, commonly after a new block causes the pool to issue updated work. Other rejection reasons, such as duplicate or invalid shares, are separate. Some dashboards display stale shares inside a broader rejected category, while others show them separately.

Does a lower ping to the pool guarantee fewer stale shares?

No. Ping provides a basic network-latency signal but does not exercise the complete Stratum session or account for job distribution, firmware job handling, intermittent packet loss, or reconnections. A Stratum- or application-level connection test is more directly relevant, and any change should still be confirmed with pool-side rejection data over a comparable time window.

Should I always use the geographically closest pool endpoint?

Geographic proximity is a reasonable starting point where a pool documents regional endpoints, but actual internet routing can differ from geographic assumptions. Test the documented options available for the mining location and compare results rather than assuming proximity alone determines the best path.

Can a VPN or proxy reduce stale shares?

Not inherently. An additional intermediary can add latency or instability rather than reduce it. Where a proxy is used deliberately, such as to aggregate multiple miners, it should be tested as part of the full miner-to-pool connection path rather than assumed to improve routing by default.

How do I know if a routing change actually helped?

Compare pool-side rejection data, specifically the stale-share category where the dashboard exposes it, across periods with similar uptime and operating conditions. Change one variable at a time so that any improvement or deterioration can be tied to the change being tested.

References

Prev
What to Do When Pool-side Hashrate Drops but Local Hashrate Looks Normal
Next
How to Troubleshoot Stratum Connection Drops on ASIC Miners