Hosted ASIC Hashrate Allocation: Billing and Proof

Hosted ASIC hashrate allocation is a contractual and accounting process. A physical miner can be pointed at one worker, several scheduled workers or a proxy that divides work, but a customer cannot verify ownership from a headline terahash figure alone. The agreement needs a named allocation method, accepted pool evidence, time boundary, fees, downtime treatment and reconciliation. This article owns split billing and trust controls, not the separate guides to mining pools, hosting selection or hashrate token products.

Define the allocation and ownership boundary

Reassess hosted ASIC hashrate allocation whenever network conditions, firmware, tariffs or official guidance changes.

Identify the customer, serials, worker names, pool accounts, allocation percentage and billing interval. A percentage without a denominator is incomplete.

Separate ownership of hardware from entitlement to mining receipts. Hosting, rental and hashpower supply can create different rights even when the dashboard looks similar.

Choose a method: dedicated worker, time scheduling, accepted-share ledger or independently metered proxy. Each method creates different variance and audit evidence.

Write the intended outcome before looking at a headline hashrate. A learning device, a useful room heater, a quiet home miner and a commercially productive machine are different purchases. The correct comparison changes when the available circuit, sound limit, heat demand, pool route or expected ownership period changes.

Use a dated decision sheet and keep manufacturer claims separate from measured results. Record the exact model, variant, power supply, firmware and operating mode. Similar product names do not make accessories, voltage, firmware or thermal limits interchangeable.

Verify physical and pool evidence

When reviewing hosted ASIC hashrate allocation, separate measured facts from forecasts so the result can be reproduced.

Obtain pool export data containing worker, accepted and rejected work, timestamps, payout method and fee. Preserve the source file and time zone.

Confirm who controls the pool account and payout address, whether the customer has read-only access and how a pool change is authorised.

Link each physical serial to its worker configuration and maintenance log. A renamed worker should not break the history.

Prefer the manufacturer specification, manual and firmware portal for identity and limits, but treat them as the starting point rather than a promise of site performance. Keep a copy of the pages and files used because support pages, downloads and product revisions can change.

Ask the seller for a serial photograph, condition statement, included accessories and a recent operating record for the actual unit. A generic product image cannot prove board revision, power supply condition, repair history or whether the miner reaches stable accepted work.

Control accounts, changes and exceptions

No conclusion about hosted ASIC hashrate allocation should rely on a single revenue snapshot or an undated specification.

Use role-based access, multi-factor authentication and an approved change record for pool, wallet and allocation changes.

Make the allocation engine fail visibly. If a proxy or scheduler stops, it must not silently direct all work to an operator account.

Define treatment for maintenance, grid curtailment, network failure, customer-requested power down and substitute hashrate.

A competent person should confirm the electrical route for the real continuous load. Check voltage, protective device, earthing, cable, connector, socket, isolation and ventilation together. Do not assume that a plug physically fitting a socket proves that the circuit is suitable for sustained operation.

Place the miner on a trusted network segment with no unnecessary inbound exposure. Change supplied credentials, use a documented wallet and pool account, set approved backup endpoints and confirm that every endpoint belongs to the intended operator before power is applied.

Reconcile accepted work and billing

Reconcile accepted work for the exact UTC or stated local interval, then apply the agreed percentage, fee and rounding once.

Compare allocated work with physical miner availability and complete site records. Investigate unexplained residual work rather than assigning it informally.

Provide the customer with opening balance, accepted basis, deductions, payout or credit, variance and any carried amount.

Measure power at the wall and compare local hashrate with accepted pool work over a representative period. Local display figures can look healthy while stale shares, invalid work, reconnects or a wrong payout address reduce useful output.

Calculate revenue and cost over a range, not one favourable day. Include electricity, pool fees, auxiliary cooling, maintenance, downtime, conversion costs and hardware value. For a heat-use case, credit only heat that replaces a cost the owner would otherwise incur.

Control split-hashrate disputes

Rank each risk by consequence and by the practical ability to detect it before purchase. A low-priced machine with uncertain firmware, exhausted cooling or a weak algorithm market can require more working capital and attention than a newer unit with a higher invoice price.

Set written stop conditions. Examples include an unsafe supply, unavailable official firmware, rejected work above the approved limit, repeated thermal shutdown, no lawful payout route or an energy break-even price below the contracted rate. A stop condition prevents sunk cost from becoming the reason to continue.

Run an end-to-end billing test

Run one full billing interval in parallel with an independent spreadsheet and reconcile every worker, fee and downtime event.

Test a worker rename, pool failover and partial outage. Require the allocation and audit trail to remain complete before accepting the process.

Begin with one unit or the smallest sensible batch. Photograph labels and connections, export the original configuration, note ambient conditions and record the start time. Watch the kernel or system log, board detection, fan behaviour, temperatures, local hashrate, pool connection and accepted work.

Do not declare acceptance from a short dashboard snapshot. Run long enough to expose heat soak, intermittent network faults and pool variance. Retain the test record with the invoice, serial number, firmware file and any seller correspondence so a later repair or warranty question has a clear baseline.

Final allocation checklist

• Confirm the exact model, variant, condition and included power equipment.
• Verify official specifications, instructions and the correct firmware route.
• Approve the continuous electrical load, airflow, heat and sound plan.
• Test network isolation, credentials, pool endpoints and payout ownership.
• Compare wall power with accepted work over a representative run.
• Model downside revenue, electricity, downtime, maintenance and resale.
• Record acceptance limits and a safe stop or return route.
• Reassess whenever firmware, network economics or site conditions change.

The checklist is deliberately evidence based. Marketing language such as home friendly, efficient or profitable has no fixed meaning without a measured operating mode and a real site boundary. The record should make it possible for another competent person to reproduce the decision.

Frequently asked questions

Can one ASIC mine for two customers?

It can be scheduled or its work can be allocated through a controlled pool or proxy process, but the method and evidence must be contractual.

Should billing use local hashrate?

Pool accepted work is normally stronger evidence of useful contribution. The contract must state the exact basis.

How are rejected shares handled?

State whether allocation uses accepted work only and whether operator-caused rejects create a service credit.

Can the host change pools?

Only under the agreed authority and change process, preserving payout ownership and audit evidence.

What happens during curtailment?

The hosting agreement should define whether there is no charge, a fixed charge, substitute hashrate or another remedy.

What should a monthly statement contain?

It should show the period, workers, accepted basis, deductions, downtime, allocation calculation and resulting payout or credit.

Conclusion

Hashrate splitting becomes trustworthy when the commercial entitlement, pool evidence and physical operation reconcile. Define the denominator and every exception, give customers practical visibility and make changes traceable. A repeatable statement is more valuable than a live number that nobody can reproduce.

Next steps

Use The Mining Shop UK tools and support pages to compare the exact hardware against your real electricity, installation, pool and operating constraints before ordering or commissioning it.

hosted ASIC hashrate allocation should be judged with current evidence, measured operating data and a clearly defined decision.