For a large ASIC fleet, switching mining pools is more than changing a Stratum URL.
A migration can create a short period of lost mining revenue, temporary connection or rejection issues, incremental engineering work, and payout-method transition effects.
The important word is incremental.
A switching-cost model should include only costs or revenue differences caused by the migration compared with the baseline in which the fleet remained on the original pool.
Normal operating costs that would have occurred anyway should not be added again.
Shares and Pool Migration
Mining pools use shares to measure contributed work.
A pool gives miners a lower share difficulty than Bitcoin's network difficulty, allowing valid shares to be submitted frequently. Only a small subset of submitted hashes also satisfy Bitcoin's much harder network requirement and become valid block candidates.
During a pool migration, the operational objective is therefore to minimize the period in which miners fail to submit valid shares to either pool and to confirm that the destination pool is receiving work normally.
See: Bitcoin Developer Guide: Mining
Main Components of Incremental Switching Cost
A practical estimate can separate four main components.
1. Foregone Mining Revenue During Cutover
If miners stop submitting valid shares while changing pools, the operation gives up the mining revenue it would otherwise have expected during that interval.
A planning estimate is:
Foregone revenue ≈ comparable daily mining revenue × cutover time as a fraction of one day
Use a recent, stable period of actual credited mining revenue where possible rather than a short rolling pool-side hashrate estimate.
2. Incremental Rejected-Share Loss
Rejected-share rates may increase during or after a migration if the new connection introduces routing, latency, configuration, authentication, or job-delivery problems.
Do not assume that rejection rates always rise after a pool switch.
Where the two pools report share data comparably, an operator can compare normal rejection rate, rejection rate during or after cutover, and the affected observation period.
If reporting definitions differ, use realized revenue and operating records instead of forcing a share-ratio comparison.
3. Incremental Labor and Direct Migration Costs
Include only work and expenses caused by the migration.
Examples may include:
- engineering time to change pool endpoints;
- worker-name or credential updates;
- monitoring the cutover;
- troubleshooting failed connections;
- remote-hands charges;
- migration-specific software or tooling;
- rollback work caused by the switch.
Routine labor that would have occurred anyway should not be included.
4. Payout-Method Transition Adjustment
Moving between PPS, PPS+, or PPLNS can change the timing and accounting of rewards around the migration.
This should be treated as an adjustment, not automatically as a cost.
A payment delay is not the same as an economic loss.
Only include a monetary adjustment when the documented payout rules create an actual difference in expected or realized rewards.
Do Not Double Count Normal Electricity Cost
If ASICs remain powered during a short cutover, they still consume electricity.
That can be useful to report as unproductive electricity consumption, but it is not automatically an incremental switching cost.
Consider the counterfactual.
If the fleet would have consumed the same electricity while mining normally, that electricity bill would have existed even without the pool switch.
For example:
Baseline, no switch
Mining revenue during interval = $1,000
Electricity cost during interval = $315
Operating contribution = $685
During cutover
Mining revenue during interval = $0
Electricity cost during interval = $315
Operating contribution = -$315
The economic difference is:
$685 - (-$315) = $1,000
That equals the foregone revenue.
Adding the same $315 electricity cost again would overstate the switching loss.
Only include electricity as an incremental migration cost if the switch itself caused additional electricity consumption relative to the baseline, such as an extra tuning or recovery cycle that would not otherwise have occurred.
A Component-Based Framework
An article-specific switching-cost framework can therefore be written as:
Estimated incremental switching cost
= foregone mining revenue during cutover
+ incremental rejected-share loss
+ incremental labor and direct costs
± payout-method transition adjustment
+ other genuinely incremental costs
Report unproductive electricity separately where useful, unless it is actually incremental relative to the no-switch baseline.
Use one currency consistently when adding values.
BTC is useful for mining-revenue comparisons. USD may be more convenient when labor and other operating costs are included.
If BTC values are converted to USD, state the BTC/USD reference price and timestamp.
Worked Example: A 1 EH/s Fleet
The following example is illustrative only.
Assume:
- fleet hashrate: 1 EH/s;
- measured power draw: 17.5 MW;
- recent comparable gross mining revenue: 0.500000 BTC/day;
- full-fleet cutover with no valid shares: 18 minutes;
- normal rejected-share rate: 0.3%;
- post-migration rejection rate for two hours: 1.1%;
- electricity price: $0.06/kWh.
Step 1: Foregone Revenue During Cutover
0.500000 × (18 / 1,440) = 0.00625000 BTC
Step 2: Illustrative Incremental Rejected-Share Effect
Using a simplified comparison:
Incremental decline = 1 - [(1 - 0.011) / (1 - 0.003)] ≈ 0.008024 ≈ 0.8024%
Applied to two hours of expected revenue:
0.500000 × (2 / 24) × 0.008024 ≈ 0.00033434 BTC
This is only appropriate when the two rejection-rate measurements are defined comparably.
Step 3: BTC-Denominated Impact Before Labor or Payout Adjustment
0.00625000 + 0.00033434 = 0.00658434 BTC
So the illustrative incremental mining-revenue impact is approximately 0.00658434 BTC before adding migration-specific labor, tooling, or any genuine payout-method adjustment.
Unproductive Electricity During the Cutover
The powered fleet would consume:
17.5 MW = 17,500 kW
18 minutes = 0.3 hours
17,500 × 0.3 × $0.06 = $315
This $315 is useful as an operational-efficiency observation.
However, if the fleet would have consumed the same electricity while mining normally, it should not be added again to the incremental switching cost.
How PPS+ and PPLNS Affect the Analysis
Payment method affects how rewards around the switch should be interpreted.
PPS or PPS-Style Components
For a PPS-style component, valid shares are generally credited according to the pool's PPS rules.
The main migration effects are therefore more likely to come from cutover downtime, rejected shares, connection quality, and fee or settlement differences.
At ViaBTC, PPS+ currently uses:
- PPS for the block-reward component, with a listed 4% fee;
- PPLNS for transaction-fee rewards, with a listed 2% fee.
These fees apply to different reward components and should not be added into a single flat 6% PPS+ fee.
PPLNS
PPLNS uses a defined recent-work window.
ViaBTC currently states that PPLNS rewards are based on the miner's share of hashrate over the last five difficulty rounds after the relevant pool-found block reaches six confirmations.
The PPS+ transaction-fee component follows the same PPLNS logic.
When leaving or joining a PPLNS pool, check how the departing pool treats shares already submitted, how the destination pool defines its eligible work window, and whether any difference is an actual expected reward change or only a timing difference.
Do not automatically classify delayed settlement as lost revenue.
See: ViaBTC: How Are Profits Calculated?
Component Model vs. Before/After Revenue Comparison
There are two useful approaches.
Component-based estimate
Use this when you have cutover timestamps, rejected-share data, migration-specific labor, and direct operational records.
Before/after realized-revenue comparison
Use this when you have comparable credited-revenue records for both pools over matched periods.
Do not use both approaches to charge the same loss twice.
For example, if realized post-switch revenue already reflects the cutover and rejected shares, do not subtract those effects again as separate line items.
Break-Even Period
Once the incremental one-time switching cost is estimated:
Break-even days = estimated incremental switching cost / expected daily recurring improvement
The denominator should reflect a comparable difference in ongoing realized economics, not only the advertised pool-fee difference.
Relevant factors can include payout method, which reward components each fee applies to, rejected-share performance, connection quality, and settlement rules.
Where practical, a split-fleet test can compare two pools during the same period and reduce distortions from changes in network difficulty and transaction-fee conditions.
If the comparison is converted into USD, use a consistent BTC/USD reference price so price movement is not mistaken for a pool-performance difference.
The test duration should reflect the fleet and payout methods involved rather than a universal fixed period.
Pre-Switch Data Checklist
Before migrating a large fleet, record:
- recent comparable mining revenue;
- current payout method;
- pool fee structure and which reward components fees apply to;
- normal rejection rate;
- destination pool URLs and ports;
- worker-naming and authentication requirements;
- current network route and latency observations;
- migration plan and rollback path;
- expected cutover window;
- migration-specific labor or contractor cost.
ViaBTC's BTC mining documentation recommends configuring multiple ports so a miner can move to the next configured connection if one becomes unavailable.
See: ViaBTC: BTC Mining
Conclusion
The cost of switching pools should be measured against the correct baseline: what would have happened if the fleet had stayed on the original pool.
A practical incremental model includes foregone mining revenue during cutover, incremental rejected-share loss, migration-specific labor and direct costs, genuine payout-method adjustments, and other costs that would not have occurred without the migration.
Normal operating electricity should not be added again if the same electricity would have been consumed in the baseline scenario.
The key is to separate one-time migration effects from ongoing pool economics and to avoid double counting the same loss through multiple formulas.
FAQ
Does a shorter cutover always mean a lower switching cost?
It reduces foregone revenue during the cutover, but other migration-specific effects may still matter.
Should electricity during the cutover be added to lost revenue?
Not automatically. If the fleet would have consumed the same electricity while mining normally, the electricity cost already exists in the baseline and should not be added again to the incremental switching loss.
Can pool-side hashrate be used to calculate switching cost?
It can support operational monitoring, but realized credited revenue and direct migration records are generally more useful for the financial calculation.
Is PPLNS always more expensive to switch into or out of?
No. PPLNS creates different reward timing and window effects, but a timing difference is not automatically an economic loss.
Should labor be included in an automated migration?
Include only the incremental labor or troubleshooting caused by the switch.