Hosted mining and staking services often look operationally simple: the customer supplies capital or equipment, the provider supplies infrastructure, and the customer receives mining output or staking rewards.
That description is too shallow for institutional due diligence.
The real exposure is a chain of legal title, physical control, cryptographic control, power availability, software integrity, subcontractors, insurance, regulatory permissions, and exit mechanics. A provider can perform well for years and still fail catastrophically at the moment when ownership, keys, insurance, or termination rights are actually tested.
The central diligence question is not “does the provider produce yield?” It is “after the provider suffers an outage, cyber incident, regulatory intervention, or insolvency, what exactly does the customer still own and control without needing the provider’s cooperation?”
A professional review should therefore distinguish five concepts that sales material frequently compresses into one: ownership, possession, control, economic entitlement, and recoverability.
Start with ownership, not yield
Risk: The customer believes it owns mining machines or staked cryptoassets, but legally holds only a contractual claim against the service company.
Likelihood: Medium. The risk rises materially when equipment is pooled, assets are substituted, wallet balances are omnibus, rewards pass through provider-controlled accounts, or the agreement says little about title and segregation.
Impact: High to critical. In an insolvency, the difference between recovering identifiable property and proving alongside unsecured creditors can dominate every other commercial consideration.
Control: The contract should identify the asset, state who owns it at every stage, prohibit unauthorised transfer or encumbrance, describe segregation, allocate rewards, and explain what happens to the asset on termination and insolvency. Physical miners should normally be capable of identification through serial numbers, model numbers, location records and inventory reconciliation. Staked assets should be traceable to validator credentials, staking accounts or addresses for which the customer’s legal and technical rights are documented.
Residual risk: Medium even after good drafting because insolvency law, liens, local property law, secured creditors, site landlords and subcontractors may affect practical recovery. A local legal opinion may therefore be proportionate for large exposures.
Mining contracts show why the wording matters. One publicly filed mining hosting agreement expressly requires the customer to have valid title or a contractual right to use the equipment and defines the machines and hosting arrangements contractually. The same agreement separately allocates insurance, termination and liability. That is a useful diligence lesson: ownership language is only one component of recoverability.
For mining equipment, ask the provider to demonstrate the chain:
customer invoice → serialised asset register → shipping receipt → site acceptance record → rack/location record → current inventory confirmation → return procedure.
An agreement that merely refers to “equivalent computing capacity” or “allocated hashrate” may describe a very different legal exposure from one under which specific machines remain the customer’s property.
A further question is whether the host, landlord, utility, lender, repair contractor or warehouse operator has any contractual or statutory lien over the machines. “The customer owns the equipment” is incomplete if another creditor can lawfully retain possession until the provider’s debts are paid.
For staking, ownership and control need to be separated even more carefully. On Ethereum, validator signing credentials and withdrawal control perform different functions. Ethereum’s official staking-as-a-service guidance explains that a customer can designate a withdrawal address under its own control even while another party operates the validator. Ethereum also distinguishes signing keys used for validator duties from withdrawal credentials used to access funds.
That architecture creates a materially different risk profile from a provider that controls both validation and withdrawal.
Preferred control architecture: the provider receives only the authority required to operate the service, while the customer retains the strongest practical control over withdrawal or recovery that the protocol permits.
Ask explicitly:
Who controls the withdrawal destination?
Can the provider change it?
Can the provider transfer, pledge, lend or restake the assets?
Are assets pooled?
Does the customer have an on-chain position attributable to it, or only an internal ledger entry?
If the provider disappears tonight, what cryptographic action can the customer perform tomorrow morning?
If the answer to the last question is “open a support ticket”, residual custody risk remains high.
Uptime must survive denominator analysis
“99.9% uptime” is not a control until the denominator has been defined.
Risk: The service level appears strong while economically important outages are excluded from the calculation.
Likelihood: High. Hosting agreements commonly distinguish maintenance, equipment failure, utility curtailment, force majeure and other excluded periods.
Impact: Medium to high. Mining revenue can disappear immediately during lost power or connectivity. Validator outages can result in missed rewards and, under adverse protocol conditions, penalties.
Control: Require an auditable service-level formula, independent telemetry, raw incident records, explicit exclusions, restoration targets, meaningful remedies and termination rights for persistent underperformance.
Residual risk: Medium. Even a well-designed SLA cannot eliminate grid failures, protocol incidents, hardware attrition or upstream internet dependency.
The same SEC-filed mining agreement provides a useful example. It defines “Online” by reference to a percentage of miners able to operate, guarantees 95% service availability, but excludes certain maintenance, equipment failure, curtailment and force-majeure periods from the calculation. It also makes termination subject to defined measurement and notification conditions.
That is precisely why customers should calculate at least three metrics:
| Metric | What it should answer |
|---|---|
| Contractual uptime | Did the provider meet the SLA after contractual exclusions? |
| Physical availability | For what percentage of wall-clock time could the asset actually operate? |
| Economic availability | For what percentage of economically attractive operating time did the customer actually receive production? |
A provider can pass the first and disappoint badly on the third.
For hosted mining, power diligence belongs beside the SLA. Determine whether the provider owns the site, leases it, purchases power directly, relies on a reseller, participates in demand-response programmes, or can voluntarily curtail customers when electricity prices make operation uneconomic.
The contract should state who benefits financially from curtailment payments and demand-response credits. The customer should also know whether a power interruption is treated as downtime, force majeure, planned curtailment, or simply an excluded event.
Review the actual mechanism for electricity pricing:
metered consumption or theoretical capacity;
utility cost or marked-up pass-through rate;
demand charges;
transmission and congestion costs;
taxes;
capacity charges;
minimum consumption commitments;
power-factor penalties;
curtailment credits;
price floors and caps.
An “electricity at cost” clause is insufficient unless “cost” is defined and invoices can be reconciled against independent metering.
Staking adds key, software and slashing exposure
Normal validator downtime and slashing are not the same risk.
Ethereum validators can lose rewards or incur penalties when they fail to perform required duties. Slashing is reserved for defined conflicting behaviours such as double proposals and conflicting attestations, and correlated slashing events can increase economic loss.
Risk: The customer bears losses caused by the operator’s key management, deployment process, software configuration or concentration decisions.
Likelihood: Low to medium for severe slashing at a competent operator, but routine missed rewards and smaller operational failures are more plausible. Correlated events deserve special attention because one common software, cloud, signing or operational fault can affect many validators simultaneously. Ethereum specifically describes distributed validator technology as one mechanism for reducing single points of failure and spreading signing responsibilities.
Impact: Potentially high, particularly where a provider operates a concentrated validator fleet using common infrastructure.
Control: The contract should separate at least four loss categories:
| Event | Contract should say who bears it |
|---|---|
| Ordinary missed rewards | Operator, customer, or SLA formula |
| Protocol-wide penalties outside operator control | Usually customer, subject to precise definition |
| Slash caused by operator error | Normally operator or agreed indemnity |
| Slash caused by compromised keys, duplicate signing or negligent deployment | Operator responsibility should be explicit where operational fault is attributable to it |
Residual risk: Medium. Even strong compensation language is only as valuable as the provider’s ability to pay after a correlated event.
The due-diligence team should therefore inspect the validator control plane, not merely request an uptime percentage.
Ask whether signing keys exist in full anywhere online. Determine whether HSMs, remote signers, threshold signing, distributed validator technology or equivalent controls are used. Establish how slashing-protection databases are backed up and transferred. Review controls preventing the same signing key from being active simultaneously on old and new infrastructure during migration or disaster recovery.
Software concentration matters as well. Ask which consensus clients, execution clients, cloud providers, operating systems, signing systems and data centres support the estate. A failover configuration that runs the same software image, same cloud region and same signing architecture is redundancy in appearance, not necessarily in failure mode. Ethereum’s own DVT documentation highlights client, machine and operator diversity as a way of reducing common-mode failure.
Withdrawal wording also needs protocol realism. On Ethereum, exiting a validator and receiving funds can take variable time depending on network conditions, and withdrawal handling depends on the validator’s credential configuration. Provider promises such as “same-day withdrawal” therefore need to distinguish the provider’s administrative processing time from protocol-controlled exit and withdrawal time.
A credible contract says:
“we will submit the required exit instruction within X hours”,
not:
“your funds will always be withdrawable within X hours”,
unless the provider genuinely controls every dependency necessary to meet that promise.
Insurance is evidence, not a substitute for liability
“Fully insured” is one of the least useful statements in provider diligence unless the policy has been examined.
Risk: Insurance exists, but not for the event the customer assumes is covered.
Likelihood: Medium.
Impact: High when equipment, cryptoassets or many validators are affected in one incident.
Control: Review the insured entity, policy type, limits, deductibles, exclusions, sublimits, aggregation provisions, territorial scope, claims basis, insurer, expiry date, cancellation notice and whether the customer is an additional insured or loss payee where appropriate.
Residual risk: Medium because insurers may dispute causation or coverage, limits may be shared among many customers, and the insured company may still be responsible for the deductible or uninsured portion.
The public mining hosting agreement cited above illustrates why certificates alone are insufficient. It allocates separate insurance obligations to the customer and host, addresses additional-insured status, and expressly states that the required insurance is not represented as necessarily adequate. Its liability section also excludes specified categories of loss, including certain lost production and revenue.
That combination matters. A provider can simultaneously have insurance and exclude liability for the loss the customer cares about.
For physical mining, investigate at least property damage, fire, flood or weather exposure, theft, equipment in transit, business interruption, machinery breakdown and third-party liability.
For staking, investigate crime and key compromise, cyber cover, professional indemnity or errors and omissions, and any dedicated slashing arrangement.
Do not assume that “cyber insurance” covers loss of cryptocurrency, validator penalties or protocol slashing. Obtain written evidence of coverage or treat those exposures as uninsured.
Then stress the policy quantitatively.
Suppose a common signing defect affects a large proportion of the provider’s validators. Does the policy limit apply per customer, per event, per year, or across the entire provider? Who absorbs the deductible? Are penalties, loss of future rewards or digital assets excluded?
The relevant number is not nominal policy limit. It is the recoverable insurance capacity available to your loss after exclusions, deductibles and aggregation.
Compliance, data and incident response belong in the same review
Hosted infrastructure can create regulatory and information-security exposure even where the provider never describes itself as a custodian.
Risk: Customer identity data, wallet information, operational telemetry or cryptographic material moves through entities and jurisdictions that were not identified during onboarding.
Likelihood: Medium to high where hosting, cloud, KYC, blockchain intelligence, support or key-management functions are subcontracted.
Impact: High if the result is unauthorised asset access, sanctions exposure, regulatory breach or inability to investigate an incident.
Control: Map the complete service chain and data flow, including subcontractors.
For each material provider ask:
Where is customer data stored?
Which KYC documents are retained?
Where are validator and wallet records processed?
Who can access production systems?
Are support staff in another jurisdiction?
Which cloud or data-centre provider sits underneath the advertised service?
Can subcontractors be changed without notification?
How quickly must a security incident be disclosed?
Can the customer obtain logs and forensic evidence?
Is evidence preserved after termination?
Who notifies regulators and customers?
For regulated institutions, the EU’s DORA third-party framework provides a useful institutional benchmark even when a particular hosting arrangement falls outside DORA itself. It requires covered arrangements to address service and data locations, data access and recovery, service levels, incident assistance, subcontracting, audit rights, termination and, for critical or important functions, exit strategies.
The broader discipline is sound: outsourcing a function does not outsource accountability for understanding how it operates.
AML and sanctions responsibilities should be similarly explicit. Depending on jurisdiction, service model and customer base, establish who performs customer identification, beneficial-owner checks, sanctions screening, wallet screening and continuing monitoring.
OFAC’s official virtual-currency sanctions guidance expressly includes miners within its discussion of the virtual-currency industry and states that applicable US sanctions obligations extend to virtual-currency transactions just as they do to fiat transactions. OFAC advocates a risk-based compliance programme rather than a single universal screening solution.
The contract should therefore answer a deceptively simple question:
Who is liable when the provider accepts a customer, wallet, payment or counterparty that should have been blocked or escalated?
Do not leave that allocation to an indemnity clause drafted after the operational workflow.
Exit rights should be designed for the bad day
The best time to evaluate termination is before signing.
Risk: The customer has a contractual right to terminate but no practical mechanism to recover equipment, assets, keys or data.
Likelihood: Medium.
Impact: Critical during insolvency, regulatory suspension, extended outage or cyber compromise.
Control: Build an executable exit plan with triggers, timelines, responsibilities, formats, costs and transition support.
Residual risk: Medium because insolvency courts, regulators, physical access restrictions, network exit queues and third-party dependencies may interfere with contractual expectations.
DORA provides a useful model here. For regulated financial entities within scope, it requires exit strategies for ICT services supporting critical or important functions, including documented transition arrangements designed to avoid business disruption, protect regulatory compliance and enable migration of services and data.
A hosted mining customer should know, before signing:
who unracks the miners;
how quickly that must occur;
whether outstanding invoices permit the host to hold equipment;
who pays shipping;
whether the customer may appoint its own logistics company;
what happens if the site landlord denies access;
what happens if the host is bankrupt;
whether firmware and configuration are restored;
whether removed machines can be tested before acceptance;
what storage charges begin after termination.
A staking customer needs an equivalent runbook:
who initiates validator exit;
who controls withdrawal credentials;
where principal and rewards are sent;
whether the provider can delay exit for operational or liquidity reasons;
how validator keys and slashing-protection history are transferred;
whether an exit requires provider co-signature;
whether the provider can suspend withdrawals under sanctions, insolvency or security clauses;
how pending rewards are reconciled.
A termination clause is not an exit plan. An exit plan identifies the technical and physical steps required when the vendor is unhelpful, insolvent, offline, compromised, or under regulatory instruction.
Finally, assess whether the vendor itself survives the shock.
Request enough financial and operational evidence to answer whether the provider can absorb:
a major site outage;
a disputed insurance claim;
a substantial slashing event;
loss of its largest customer;
termination of its principal power contract;
a cloud or key-management outage;
regulatory suspension in a major market;
emergency customer withdrawals;
a material cyber incident.
A company may have excellent day-to-day operations but inadequate balance-sheet capacity for the event its indemnities promise to cover.
That is counterparty credit risk disguised as an operational SLA.
Contract questions that expose the real arrangement
The following questions are more useful than asking whether a provider is “institutional grade”.
| Area | Question to put into diligence | Evidence expected | Material warning sign |
|---|---|---|---|
| Ownership | Who legally owns the equipment or staked asset at every point in the service? | Contract, legal opinion where material, asset records | “Economic ownership” without legal definition |
| Identification | Can each physical asset or validator be attributed to the customer? | Serial numbers, validator IDs, reconciliation | Only pooled capacity or internal accounting |
| Encumbrances | Can the provider, landlord, lender or other party assert a lien? | Contract, financing disclosure, legal analysis | Broad provider lien over customer property |
| Reuse | Can assets be pledged, lent, restaked or otherwise reused? | Express contractual prohibition or defined permission | Silence or broad discretion |
| Withdrawal keys | Who controls the final withdrawal destination? | Key ceremony or address evidence | Provider controls both signing and withdrawal |
| Signing keys | How are validator signing credentials secured? | Architecture, HSM or DVT evidence, access controls | Exportable keys on ordinary servers |
| Slashing | Who pays for operator-caused slashing? | Indemnity and compensation formula | “All protocol losses are customer risk” |
| Uptime | What is included in the denominator? | SLA calculation and historic raw data | Broad exclusions that remove common outages |
| Power | Who actually contracts with the utility or energy supplier? | Power agreement or substantiated summary | Host cannot evidence secure power rights |
| Curtailment | Who can switch equipment off, and who receives curtailment revenue? | Contract and utility mechanism | Host has unilateral economic curtailment rights |
| Insurance | Which customer loss scenarios are genuinely covered? | Policy schedule, endorsements, exclusions | Certificate only |
| Liability | Are lost rewards or production excluded from damages? | Liability clause and caps | SLA remedy is commercially trivial |
| Data | Where do KYC records, wallet data and operational logs go? | Data map and subprocessor list | Undisclosed fourth parties |
| Incidents | When must the customer be notified? | Incident-response SLA | “Promptly” without defined severity or timing |
| Audit | Can the customer validate controls rather than rely on marketing material? | Audit reports, testing rights, assurance reports | Absolute prohibition on meaningful assurance |
| Insolvency | Can the asset be recovered without management cooperation? | Insolvency opinion, segregation evidence, exit test | Recovery depends on support staff remaining available |
| Termination | How long from notice to physical or cryptographic control? | Tested runbook | Right to terminate but no delivery obligation |
| Concentration | Which common providers could disable the whole service? | Dependency map | One region, client, cloud, signer or data centre |
| Financial resilience | Can the provider fund its indemnities after a correlated loss? | Financial statements, insurance, liquidity evidence | Liability promise materially exceeds resources |
The last column matters most.
A diligence answer should not be accepted merely because it is technically correct. It should demonstrate that the control survives the scenario in which it is needed.
The research question that should drive the diligence
Primary research question
In a simultaneous provider outage and insolvency scenario, what proportion of customer assets can be recovered, withdrawn, migrated or independently operated within a defined period without any affirmative action by the provider, and what technical, contractual and legal evidence proves that result?
This question tests several assumptions at once.
For mining, perform the exercise against actual equipment records. Select sample serial numbers, trace title, identify their physical racks, examine liens, model site-access failure, and determine exactly how the machines would leave the facility.
For staking, select sample validators and trace deposit records, signing-key architecture, withdrawal credentials, exit authority, rewards flow and slashing-protection records. Then ask whether a customer can exit or migrate when the provider’s normal control plane and personnel are unavailable.
For both models, include the dependencies underneath the named vendor. A provider that needs one cloud account, one remote signer, one facility landlord, one power counterparty, one KYC vendor or one administrator to execute the recovery may still contain a material single point of failure.
The answer should be measurable. For example:
“95% of customer assets can be independently identified, and 90% can be recovered or placed into a customer-controlled exit process within 48 hours without provider management approval.”
That is a control statement capable of testing.
“We take custody seriously” is not.
Final risk position: treat hosted mining and staking as outsourced critical infrastructure with an embedded property-rights question. The acceptable provider is not necessarily the one promising the highest uptime or yield. It is the one whose title, keys, liabilities, power dependencies, data flows, insurance and exit procedures remain intelligible when normal operations have stopped.
Institutional caution does not require eliminating every outage, slashing event, insolvency or regulatory shock. That is impossible. It requires knowing who is liable, where the assets and data actually sit, what happens during the outage, how the customer exits, and whether the vendor has sufficient technical and financial resilience to honour those promises when the failure nobody budgeted for finally occurs.