Remote Hands: What a Mining Farm Should Handle for You
Hosted miners spend weeks worrying about the wrong number. At 20 J/TH, ten 250 TH/s machines produce about $91.18 of net income a day against $72.00 of power, so a total three-day outage costs roughly $57.55 of contribution — less than the value of one hashboard that a failed fan can destroy while the site waits for instructions. Remote hands is a hardware-preservation service first and an income-protection service second.
Key takeaways
- Price downtime on contribution, not gross income: ten 250 TH/s machines at 20 J/TH lose about $57.55 of contribution across three full days offline, because stopped chips stop drawing power.
- The strongest case for remote hands is hardware preservation — a fan failure that is not addressed can cost a board, which is worth far more than the days of lost hashrate.
- Insist on three things in the service definition: a response window in hours, photo evidence with timestamps, and an agreed spare-parts list held on site.
- Whatever the site reports, verify the fix in the pool account: a worker back at its recorded hashrate is the only proof that the repair worked.
The core idea
Remote hands means physical work done by someone else's staff on your hardware: swapping a fan, reseating a hashboard, replacing a power supply, changing a cable, flashing firmware, reading a serial number, taking a photograph. It exists because hosting separates ownership from proximity — the machine is yours and the hands are theirs.
The service is usually described in hours of response, which is the wrong unit for a mining contract. What matters is the sequence: whether the site notices the fault, whether it can act without asking, whether it has the part, and whether it documents what it did. A site with slow response but generous authority and full spares will outperform a site that answers the ticket in fifteen minutes and then waits three days for an approved part.
How it plays out at scale
Run the numbers on a ten-unit cluster of 250 TH/s machines at 20 J/TH, with difficulty at 132.76 T and BTC at $84,692. Gross income is $9.50 per machine per day, or $94.98 for the cluster; after the listed 4% fee on the block-reward component, $91.18 remains. The cluster draws 50 kW — 1,200 kWh a day, which is $72.00 at $0.06/kWh. Contribution is $19.18 a day.
That last figure is the one to negotiate with. Income at risk from a stopped cluster is $91.18 a day, but the true loss is the contribution, because the electricity not consumed is a cost avoided. Any remote-hands premium should be compared against the contribution, not the revenue — and on efficient hardware the contribution is a small fraction of the headline income figure.
| Machines offline | Net income forgone | Power avoided | True loss (contribution) |
|---|---|---|---|
| 1 machine (250 TH/s) | $27.36 | $21.60 | $5.76 |
| 10 machines (2.5 PH/s) | $273.55 | $216.00 | $57.55 |
| 40 machines (10 PH/s) | $1,094.19 | $864.00 | $230.22 |
Now repeat the same table on 30 J/TH hardware and the sign flips: the power avoided exceeds the income forgone, so every day offline is a day the site saves money. That is not an argument for downtime; it is an argument for checking a rig's efficiency before paying for a service-level agreement designed to keep it running. A miner profitability ranking answers that question in one look at current difficulty and price.
Two scenarios compared
Site A — 4-hour response, spares on site, documented authority. A fan fails at 02:00. The site detects the temperature alarm, replaces the fan from stock before the next shift change, photographs the part and returns the unit to full hashrate. Total exposure is a few hours at reduced power, and the board survives. One documented repair costs the site a fan; the same repair deferred costs the miner a board.
Site B — customer sends a technician, 72-hour window. The same fan fails. The unit runs hot for three days, throttles, then shuts down. Income lost is about $27.36 net, power avoided $21.60, true loss $5.76 — and the replacement part turns out to be a hashboard rather than a fan, because the note about the original fault arrived after the damage. The arithmetic of the incident is small; the arithmetic of the equipment is not.
The comparison is not really about response time in hours. It is about whether the site has authority to act before asking, whether the right spare is on the shelf, and whether the action is documented well enough for you to tell a repair from a failure. A cluster that reports the fault but cannot act on it is a monitoring service, not remote hands.
What does change on the pool side is your ability to verify. When hosted rigs run as named workers in the same account as the machines you operate, the hashrate series tells you whether the repair actually restored output, and how long the unit was below its recorded fingerprint. Farm-managed hosting through ViaBTC Mining Farms keeps that visibility continuous, which is the difference between trusting a ticket update and reading the data yourself.
It also keeps the fleet flexible. If a chain's economics change, a multi-coin mining pools account lets hosted units be re-pointed at BCH, LTC/DOGE merged mining, KAS or another supported chain without a site visit, which is exactly the situation where physical hands are least useful and configuration changes matter most.[1]
Common failure modes
- Restart as diagnosis. A unit cycle-powered and returned to the pool looks fixed in a ticket and fails again in two days, which is worse than an honest "part needed".
- Photos without timestamps or context. A close-up of a new fan proves nothing unless it shows the unit serial in the same frame.
- Third-party firmware changes. If the site reflashes as part of routine maintenance, your performance baseline changes underneath you.
- No agreed spare-parts list. "We will order it" converts a same-day repair into a lead-time question the miner never priced.
- Business-hours access only. Hardware failures do not schedule themselves, and a 12-hour overnight window is a real cost even when the site calls it free.
- Alert fatigue. Sites that mute fleet-wide alerts to avoid noise also miss the single unit that is throttling toward failure.
None of those failures is visible in an availability percentage. All of them are visible in per-worker hashrate, which is the argument for keeping the pool account as the source of truth and treating site reports as commentary.
Frequently asked questions
Can I mine more than one coin at the same time?
Yes. Merged mining lets a machine secure a parent chain and an auxiliary chain together, and multi-coin pools support switching between chains without moving hardware.
Do mining pools cost anything to join?
Joining is free; the pool earns from its fee on settled payouts, which appears as a percentage of the block-reward and transaction-fee components.
How much downtime does remote hands actually save?
Less income than most miners expect and more equipment than they realise. Three days offline on ten 250 TH/s machines costs about $57.55 of contribution at 20 J/TH — while a fan failure that becomes a board failure costs many times that.
What should be written into a remote-hands agreement?
A response window measured in hours, authority to act without prior approval up to an agreed parts value, a list of spares held on site, and photo evidence with the unit serial in frame for every intervention.
Write the service definition, then verify it
List the three things that decide whether remote hands helps you — response window, on-site spares and documentation — and put them in the contract with numbers attached. Then set the operational check: compare per-worker hashrate against each unit's recorded baseline every week, so a repaired machine and a quietly failing one are distinguishable without a site visit. Do that, and the service stops being a line item you hope delivers and becomes one you can audit from your own dashboard.
Data and sources: ViaBTC fee and farm hosting documentation[1]. Network difficulty (132.76 T), network hashrate (1,003 EH/s) and the BTC price of $84,692 come from public chain data and market feeds read on 21 September 2026; all income, power, contribution and downtime figures are own calculations from those inputs. Service-response scenarios are illustrative and are not descriptions of any particular operator's terms.