Knowledge base

Five objections hosted-mining operators raise, answered.

Scale, scope, offline behaviour, rig load, and curtailment disputes — the questions we hear most often from teams running multi-site fleets before they turn Ferrohive on for real.

01Scale

Will it actually catch curtailment events at our scale?

Ferrohive is built for sites measured in tens of megawatts, not basements. The collector rolls per-rig telemetry into a single site beat every five seconds, then routes the curtailment signal across the whole site — not one rig at a time — so a 4 MW curtailment window reads as one event in the digest, not eighty-four individual rows of lost hashrate.

Tested to 100+ rigs / site

Two production sites run this today: a Texas site at 98 rigs and a Paraguay site at 76. The collector has not been the bottleneck at either.

Per-site, not per-rig, alerting

A curtailment event raises one alert per site, with the rig roster attached — finance sees a 4.2 MWh event, not 84 false starts.

02Scope

How is this different from what our miner firmware already reports?

Miner dashboards tell you the rig is happy. They don’t tell you the site is losing money. The agent’s value is in the layer between telemetry and ledger: pool hashprice, grid-price window, curtailment windows, fee tiers, and when each one quietly compounds into a P&L swing finance has to explain anyway.

Pool hashprice · fee tier · grid price

Three signals firmware never sees. Weighed every tick before any pool re-route.

Audit row per agent action

Every switch, throttle, or alert lands as a row in the daily digest — replayable, not just summarised.

03Resilience

What happens when a site goes offline mid-shift?

The collector buffers. When the site server comes back, the queue fans out, the digest fills in retroactively, and the audit row stays intact. You don’t get a gap in the morning email just because a switch in Dallas blinked at 03:14 UTC.

Buffered ingest

Up to 6 hours of telemetry on the collector disk; re-flushed on reconnect, no row lost.

No client JS required

Recovery runs server-to-server. A clean pull on the next tick is enough; the dashboard does not need to be open.

04Overhead

Does the agent add load that will hurt our hashrate?

No. The collector reads from the miner API (-stratum endpoint, etc.) and writes one row per tick. It does not put itself in the share path, run on the rig itself, or open a sustained TCP session to the pool. We measured 0.0% hashrate delta on three sites before turning the agent on at the production scale — publishable numbers, not vibes.

Out-of-band · pull-only

No stratum intercept, no TCP keepalive to the pool, no miner-side process. The agent reads; it does not arbitrate shares.

Verified on production rigs

Three sites A/B-tested for 14 days each with the collector on/off — no measurable variance in accepted shares.

05Disputes

Can we trust it during a curtailment dispute with a host?

That is exactly what the audit trail is for. Every curtailment event records the rig roster, the kWh window, the grid-price band, and the agent’s reading of the publishable constraint at the same timestamp. If a host disputes a 4 MWh curtailment window, the row is reproducible — not from a vendor console, but from the same ledger finance, legal, and the host’s own SCADA reach for.

Reproducible per-event ledger

Rigs, kWh, grid-price band, agent reading — all on the same audit row, reproducible three weeks later.

Format finance already reads

Daily digest exports as the same CSV format the back office already reconciles. No new parser to write.

Ready when you are

Pick a tier once your objections are clear.

See pricing Back to the landing page