What "without downtime" actually means
To switch mining pools with minimal disruption, confirm the destination pool's connection details, test the destination and backup entries on one miner, set the intended pool as primary, and verify that it accepts shares under the correct worker. Preconfigured backups help the firmware respond automatically if the primary connection fails.
Before a miner can submit valid shares to the destination pool, it needs a working Stratum connection, the appropriate worker credentials, and valid jobs from that pool. However, these requirements do not mean that every switch must stop all hashing or that the old connection must be closed before the new one can be established. Mining software can support multiple pools and runtime switching, as illustrated by the CGMiner documentation. The behavior of a particular ASIC depends on its firmware, existing connections, and how it applies configuration changes.
The realistic objective is to minimize interruption to useful mining work. Continuous local hashing alone does not prove that the destination pool is receiving and accepting shares. A prepared switch can reduce the need for manual intervention, but it does not guarantee a completely uninterrupted transition.
What changes when you switch pools
A pool switch changes three things: the Stratum server the miner connects to, the worker credentials associated with that connection, and the source of the mining jobs the ASIC works on. It does not change the hashing algorithm the ASIC runs or its local hashrate setting.
According to the Bitcoin Developer Guide, Stratum operates as a two-way TCP connection through which the pool supplies the data needed to construct candidate block headers and defines the share target the miner must meet; the miner then submits shares back for validation (Bitcoin Developer Guide — Mining). Because this target and job data come from the pool itself, a miner cannot perform work credited by the destination pool until it has received valid jobs from that pool.
Stratum V2 defines a Reconnect message that can redirect a client to a different upstream node, but only within the same pool authority. That message cannot redirect a miner to an unrelated pool (Stratum V2 Specification — Protocol Overview). This restriction applies to that specific protocol message, not to all ways of switching pools. The destination pool's address and credentials need to be configured, but if they are already saved, supported software or firmware can switch to that entry without requiring the operator to enter them again.
A practical switching workflow
The following sequence reflects how pool-side documentation and ASIC firmware are typically structured. Exact menu names vary by manufacturer and firmware version, so operators should confirm behavior against their own equipment before relying on it at scale.
1. Confirm the destination pool's current connection details
Before touching any miner, verify the coin, algorithm, Stratum URL, port, worker-name format, and password convention directly from the destination pool's official setup page. Do not reuse a URL copied from an old configuration, a forum post, or a screenshot, since pool infrastructure and recommended ports can change over time. For Bitcoin, ViaBTC's setup documentation lists the current Stratum URL and both a primary and an alternate port, along with the required worker-name format (ViaBTC Help Center — BTC Mining).
2. Record the current working configuration
Before editing anything, note the existing pool entries exactly as configured. This gives the operator a known-working fallback to revert to if the new endpoint, credentials, or network path turns out to be incorrect.
3. Configure and test prioritized pool entries
Many ASIC firmware interfaces expose multiple pool slots with descending priority — commonly labeled Pool 1, Pool 2, and Pool 3. Bitmain's Antminer S21 Hyd. user guide documents this structure, with lower-priority pools used only when all higher-priority pools are offline (Bitmain Antminer S21 Hyd. User Guide, section 4.2).
For a planned migration, place the destination pool first in the priority list. Backup entries provide automatic fallback if that connection becomes unavailable; simply adding the destination as a lower-priority backup does not make it the active pool while a higher-priority pool remains online.
A practical application is configuring two ports for the same pool. ViaBTC's BTC mining documentation lists ports 3333 and 443 and recommends multiple entries so the miner can move to the next configured port if one cannot connect. This provides an alternate connection option, although two ports on the same pool are not independent pool backups.
For a miner using three prioritized slots, a migration to ViaBTC could use the following arrangement:
| Slot | Connection | Worker and password |
|---|---|---|
| Pool 1 | stratum+tcp://btc.viabtc.io:3333 |
Your ViaBTC userID.workerID; password is optional |
| Pool 2 | stratum+tcp://btc.viabtc.io:443 |
The same ViaBTC worker details |
| Pool 3 | Your recorded, working BTC pool URL | That pool's existing worker details and password convention |
Test the destination and each backup separately on one miner before relying on this arrangement. Temporarily select each entry as the active pool, using the controls supported by the firmware, and check that it accepts shares. Restore the intended priority order after testing. For multiple machines, verify the final configuration on that miner before applying it to the rest.
4. Keep backup entries compatible with the configured algorithm
A backup entry must be compatible with the ASIC's hashing algorithm and the mining protocol supported by its firmware. Pointing a SHA-256 Bitcoin miner at an endpoint for a different algorithm will not function as a usable fallback, regardless of how the slot is labeled in firmware.
Mining the same coin is a separate operational choice. BTC and BCH both use SHA256, and ViaBTC's setup guides list overlapping supported miner models (ViaBTC Help Center — BTC Mining, BCH Mining, algorithm information). If the goal is to continue mining BTC, use BTC backup entries. Choosing another compatible coin requires a deliberate decision and the correct configuration for that coin.
5. Apply and verify the new configuration
After testing the entries and confirming the intended priority order, apply the final configuration. Avoid unnecessary repeated edits during the migration. Check the miner's local status page or log to confirm the active pool and worker, receipt of new jobs, and accepted shares — not just submitted shares.
Also confirm that the intended worker appears under the correct account on the destination pool. If the miner has fallen back to another entry, local hashing may continue even though the planned migration has not succeeded. Use the recorded configuration to revert if the destination cannot be made to work.
6. Allow a stabilization period before judging the result
Immediately after a switch, local and pool-side readings may not yet reflect steady-state operation. ViaBTC's documentation recommends allowing roughly 10–15 minutes of stable operation before checking worker status and earnings on its BTC mining page; this is presented as ViaBTC's own monitoring guidance rather than a universal benchmark, and operators using other pools should follow that pool's equivalent recommendation if one is published.
7. Compare pool-side and local data using matching time windows
A common error after a pool switch is comparing hashrate readings calculated over different periods. ViaBTC's support documentation notes that its real-time hashrate figure is calculated from the previous 10 minutes, while its daily hashrate reflects the previous 24 hours (ViaBTC Help Center — Why Is Pool Hashrate Lower Than Miner Hashrate?).
The miner's display refresh interval is different from its averaging window. A value refreshed every few seconds can still represent an average over a much longer period. Check whether the local figure is an instantaneous estimate, a rolling average, or an average since startup before comparing it with the pool's corresponding metric. Treat the pool dashboard as the record of what that pool has accepted and its resulting hashrate estimate, and avoid drawing conclusions from readings with mismatched windows.
Interpreting rejected shares after a switch
If rejected shares rise noticeably after a pool change, check the rejection-rate figure on the new pool's dashboard rather than assuming a problem with the pool itself. Rejection rate is a measure of share-submission quality — distinct from local hashrate and pool-side hashrate estimates — and elevated rejections can stem from network delay between the miner and the new server, firmware mismatches, or hardware issues such as overheating. ViaBTC's troubleshooting documentation treats a rejection rate within roughly 3% as typical for its own service, while also identifying network delay, firmware, and thermal conditions as contributing causes; this figure should be read as ViaBTC's own reference point rather than a fixed industry threshold, since acceptable rejection rates can vary by pool and connection quality (ViaBTC Help Center — What if the Rejection Rate is High?).
For larger operations
Sites running a large number of ASICs may benefit from an optional local intermediary, commonly called a miner agent server. ViaBTC documents an agent that consolidates pool communication, distributes jobs to local miners, and forwards their submissions to the pool. Its documented role is to reduce bandwidth use and problems caused by network congestion or delayed job updates; this does not establish a guarantee of uninterrupted cross-pool migration.
ViaBTC's miner agent server currently supports BTC and LTC. This is relevant primarily to operations managing many machines at once and is not a requirement for an individual ASIC or a small home-mining setup (ViaBTC Help Center — An Introduction to Miner Agent Server).
Summary
Switching pools without extended downtime depends on preparation rather than reaction. Confirm the destination pool's current connection details, test the destination and backup entries, set the intended priority order, and verify accepted shares under the correct worker. Then assess hashrate using comparable time windows. Preconfigured backups can reduce manual intervention, while the actual interruption depends on the firmware and connection state. A completely uninterrupted switch should not be assumed or promised.
FAQ
Can I switch pools with absolutely no interruption to hashing?
A completely uninterrupted switch cannot be guaranteed. The destination pool needs a working connection and must supply valid jobs, but that does not inherently require all hashing to stop or the old connection to be closed first. Actual behavior depends on the miner's firmware, existing connections, and how settings are applied. Verify accepted shares on the intended pool rather than relying only on local hashrate.
Does setting an alternate port improve mining performance?
No. An alternate port, such as the backup port some pools document alongside their primary endpoint, exists so the miner can connect if the primary port is unreachable. It is a connection-continuity measure, not a setting that increases earnings or reduces network latency.
Why does my pool dashboard show a different hashrate than my miner right after switching?
The figures may use different averaging windows. ViaBTC's real-time hashrate reflects the previous 10 minutes and its daily figure reflects the previous 24 hours. Your miner may show an instantaneous estimate, a rolling average, or an average since startup. A fast display refresh does not establish a short averaging window. Identify the local metric and compare readings over comparable periods once operation has stabilized.
Should I configure a backup pool even if I don't plan to switch soon?
Configuring a valid backup entry in the miner's priority list is a reasonable precaution so the firmware can fall back automatically if the primary connection becomes unreachable, but it is an operational choice based on each operator's risk tolerance rather than a mandatory requirement.
Is port 443 automatically an encrypted connection?
Not necessarily. A port number alone does not establish an encrypted Stratum connection; whether a connection uses TLS/SSL depends on what the pool documents for that specific endpoint and whether the miner's firmware supports it.
References
- Bitcoin Developer Guide — Mining
- Stratum V2 Specification — Protocol Overview
- ViaBTC Help Center — BTC Mining
- ViaBTC Help Center — Why Is Pool Hashrate Lower Than Miner Hashrate?
- Bitmain Antminer S21 Hyd. User Guide — V4.0.14
- CGMiner — README
- ViaBTC Help Center — BCH Mining
- ViaBTC Help Center — How to Connect NiceHash to ViaBTC?
- ViaBTC Help Center — What if the Rejection Rate is High?
- ViaBTC Help Center — An Introduction to Miner Agent Server