1 Contracting parties and acceptance
1.1These Terms and Conditions (Terms) govern the services supplied by BitHash Limited (BitHash, we, us or our) through https://bithash.ae and its associated service platforms (Platform). BitHash Limited holds licence number 07010605 and has its registered address at Office A, Innovation City Business Centre, RAK BANK ROC Office, Ground Floor, Al Rifaa, Sheikh Mohammed Bin Zayed Road, Ras Al Khaimah, United Arab Emirates. The client identified in the accepted service order, quotation, hosting agreement or project agreement (Order) is referred to as the Client, you or your. BitHash Limited is responsible for the obligations it accepts under the Order. No affiliate or individual provides a personal guarantee unless expressly agreed in a separately signed instrument.
1.2The agreement between BitHash and the Client (Agreement) comprises the accepted Order, any expressly incorporated service level agreement (SLA), these Terms including Schedules A and B, and policies or fee schedules expressly incorporated and supplied or made accessible before acceptance. Subject to mandatory applicable law, precedence is: the Order and its agreed amendments; the SLA for service measurement and credits; the main body of these Terms; Schedules A and B; and incorporated policies and fee schedules. Specific refund arrangements, price commitments, delivery obligations and other negotiated commercial terms in an Order prevail over inconsistent provisions below. An SLA does not change payment obligations, ownership or liability caps unless the accepted Order expressly incorporates that change.
1.3The Agreement is formed when both parties accept the Order. Client acceptance may be recorded by signature, affirmative electronic acceptance, or payment against an Order that expressly incorporates these Terms, provided a copy or accessible link was supplied before payment. Browsing the website does not create a paid service contract. BitHash will retain the applicable version and evidence of acceptance. These Terms apply to Orders accepting this version and do not retrospectively amend an existing agreement.
1.4Unless expressly stated otherwise, quotations are invitations to place an Order and remain subject to acceptance by BitHash. Any conditions relating to cleared payment, compliance checks, stock, power availability or technical specifications must be disclosed before acceptance. Amendments require the agreement of authorised representatives of both parties, except where the Agreement or mandatory law expressly permits otherwise. Electronic signatures and written electronic approvals may be used where legally valid.
1.5The Order must identify its unique reference, applicable Terms version, incorporated schedules, Client identity and authorised signatories or electronic approvers. Before acceptance, BitHash will make the contractual documents available for download or retention and identify material payment, cancellation, liability and service limitations. Acceptance records may include the document version, date, time and method of acceptance, and proportionate authentication information. No pre-ticked box or mere website use substitutes for affirmative acceptance of a paid Order.
1.6The Order will identify operational contacts and representatives authorised to approve commercial variations. Operational instructions do not, by themselves, change price, scope, refund rights or liability allocation. A change agreed by email or other written electronic communication must be sufficiently clear, attributable to an authorised representative and legally valid. This clause does not displace mandatory rules about actual or apparent authority or binding representations.
2 Services and mining risks
2.1Services may include ASIC hardware sales and sourcing; air-cooled or hydro-cooled mining hosting; cloud hashrate; diagnostics, repair and maintenance; turnkey mining or data centre development; and operations and management (O&M). Only the services and deliverables expressly included in an accepted Order are supplied. Artificial intelligence (AI), high-performance computing (HPC) and other data centre colocation services require agreed technical specifications, data responsibilities and an SLA before activation.
2.2Digital asset mining involves substantial commercial and operational risk. Profitability depends on factors including asset prices, network difficulty, block rewards, halvings, mining pool performance, hardware efficiency, cooling conditions and regulatory requirements. These factors may reduce or eliminate returns, and equipment may depreciate. The Client may lose some or all of its expenditure. BitHash does not guarantee profit, payback, a fixed yield or recovery of capital. Calculators, forecasts and projections are estimates based on stated assumptions.
2.3The Client is responsible for its own commercial, investment and tax decisions and for obtaining independent advice where appropriate. Website content and projections are general information and do not constitute personalised investment, legal or tax advice. Nothing in these Terms excludes responsibility for fraud, actionable misrepresentation or mandatory disclosure obligations, or limits an express contractual service commitment.
2.4A commercial licence does not constitute financial services authorisation or regulatory endorsement. These Terms do not authorise custody, exchange, investment management or any other regulated activity. A service requiring additional permission will be offered only when the necessary authorisations and contractual arrangements are in place. Its regulatory classification is determined by applicable law and the actual service structure.
2.5BitHash will identify before acceptance any material facts known to it concerning the proposed service, including material capacity, permitting, delivery, condition or operational limitations, where disclosure is required by law or necessary to avoid misleading the Client. Marketing statements and projections must be consistent with the accepted service commitments. General disclaimers do not cure a misleading statement or remove a binding representation.
3 Eligibility and compliance
3.1Individual Clients must be at least 18 years old and have legal capacity to contract. A person acting for an entity must have authority to bind it. The Client warrants that it has lawful ownership of, or authority to use, its equipment; its funds are lawfully obtained; the information it supplies is accurate and complete; and its use of the services is lawful in the relevant jurisdictions.
3.2BitHash may request proportionate identity, beneficial ownership, source of funds, source of wealth, equipment ownership and authority documents for risk-based know-your-customer (KYC) and know-your-business (KYB) checks. The Client must notify BitHash of material changes within seven calendar days. BitHash may decline an application on lawful grounds or suspend a transaction where reasonably necessary for sanctions screening, fraud prevention, compliance checks or a binding legal direction.
3.3Politically exposed person status is subject to appropriate risk assessment and enhanced checks; it is not automatically a prohibition. Applicable sanctions and legal restrictions control eligibility. BitHash may report or disclose information where required or lawfully permitted and may be prohibited from notifying the Client.
3.4Clients must protect credentials, enable available security controls, maintain accurate contacts and promptly report suspected compromise. BitHash may rely on authenticated instructions unless it knows or reasonably should know they are unauthorised. Each party remains responsible for its own security failures. Resale, account sharing and unauthorised third-party operation require written approval.
3.5A third-party payer, nominee, broker or referral agent must be disclosed before payment or asset delivery. BitHash may require evidence of the relationship, ownership and authority and may reject an arrangement on lawful compliance grounds. A third-party payment does not itself make the payer a contracting client or asset owner. Refunds normally return to the verified original payment source, subject to law, payment-provider requirements and any verified alternative agreed in writing. No refund will knowingly facilitate unlawful third-party transfers.
4 Fees, payments and taxes
4.1The Order will specify the prices, currency, deposits, invoicing cycle, payment dates and included services. If no payment deadline is agreed, invoices are payable within seven calendar days of issue. VAT and other applicable taxes will be stated and charged in accordance with law; any requirement to display tax-inclusive prices takes precedence. A tax or charge imposed on BitHash is passed through only where lawfully and expressly chargeable to the Client.
4.2Fees may include hardware, hosting, electricity, installation, cooling, repairs, management, storage, logistics and project costs, but are payable only where stated in the Order or subsequently agreed. Fixed prices and locked tariffs remain unchanged for the agreed period unless an express adjustment mechanism, an agreed written variation or mandatory law permits a change. A website fee update does not retrospectively increase the price of an accepted Order.
4.3Pay only to the company bank account or wallet specified in the Order or an authenticated company instruction. Verify any change through an independently established contact. BitHash does not authorise payment to employees or personal accounts unless specifically documented and lawfully approved. Clients must supply payment references and evidence when requested.
4.4A digital asset or payment token may be used only where its acceptance for the relevant transaction is permitted by applicable law and expressly agreed in the Order. An agreed payment method does not override regulatory restrictions. Where permitted, the Order will specify the asset, network, authorised address, valuation currency, conversion source and time, required confirmations and charges. Stablecoin parity with a fiat currency is not guaranteed. The Client bears losses caused by its own incorrect address, network or asset selection. Reasonable recovery costs require prior approval. BitHash remains responsible for errors in payment instructions it supplies.
4.5Payment is treated as cleared when received in available funds, any agreed blockchain confirmations have occurred and applicable compliance checks permit use. The Client bears bank, network and conversion charges expressly allocated to it in the Order. The Client should explain any invoice dispute in writing promptly, ordinarily within ten calendar days of receipt. Failure to object within that period does not waive mandatory rights or the correction of substantiated billing errors. Undisputed amounts remain payable.
4.6Overdue, undisputed amounts may result in suspension in accordance with clause 10. BitHash may recover reasonable, documented collection costs and any expressly agreed late-payment charge, to the extent permitted by law and subject to applicable judicial assessment. No late-payment charge arises solely under these Terms.
4.7A payment-instruction change must be issued through an authenticated company channel and independently confirmed using a previously established company contact. BitHash will not require a Client to rely solely on a new telephone number, new email address or contact detail supplied in the change request. Any material mismatch between beneficiary, contracting entity, asset, network or amount must be resolved before transfer. These procedures allocate verification duties without excusing either party's own actionable security failure or inaccurate instructions.
4.8If a previously agreed payment method becomes unlawful or unavailable for regulatory reasons, the parties will promptly agree a lawful alternative and a reasonable payment timetable. Conversion, token depegging or refund valuation will follow the expressly agreed Order methodology and applicable law; neither party may impose an undisclosed exchange rate or spread. No token payment clause represents that BitHash holds a payment, exchange or custody authorisation.
5 Deposits, refunds and set-off
5.1A security deposit secures the Client's payment and performance obligations and is not automatically a non-refundable fee. BitHash may apply it against amounts lawfully due and will provide an itemised statement. The Client must replenish any shortfall within seven calendar days of notice. Unless the Order provides otherwise, unused security will be returned within thirty calendar days after termination, lawful equipment release and final reconciliation, subject to any lawful hold. BitHash will complete reconciliation without unreasonable delay and will not withhold an undisputed balance solely because another amount remains disputed.
5.2Reservation payments, procurement advances and prepayments are governed by the expressly agreed terms of the Order. Where cancellation or termination is permitted, BitHash may retain earned fees, documented non-recoverable commitments and agreed lawful cancellation compensation, without double recovery. Any refundable balance will be paid within thirty calendar days after it is established, with reconciliation completed without unreasonable delay. This clause does not grant a general right to cancel or an unconditional refund. Mandatory refund rights and any signed conditional refund or replacement-and-takeover arrangement prevail.
5.3BitHash may set off legally due sums against amounts payable to the same Client by the same contracting entity, subject to law, contractual authority and an itemised statement. Protected, segregated or third-party funds cannot be applied without lawful authority. There is no automatic cross-entity pooling.
5.4The Order will distinguish refundable security from reservation fees, procurement advances, service prepayments and milestone payments, and state the purpose and earning or commitment trigger for each amount. Calling a payment a deposit or non-refundable does not alone determine its legal treatment. Where retention is claimed, BitHash will identify the earned service, approved commitment or agreed lawful compensation and account for supplier refunds, resale recoveries and avoided costs relevant to the same loss. No sum will be recovered twice.
5.5A replacement-client or takeover arrangement is effective only under its signed conditions, including required consents, assumption of obligations, acceptance of the replacement client and cleared replacement funds where agreed. A request alone does not release existing obligations or create an immediate refund entitlement. BitHash will not unreasonably obstruct steps it expressly agreed to facilitate. These Terms neither broaden nor reduce the signed arrangement's eligibility window, conditions or repayment deadline.
6 Hardware sales, sourcing and delivery
6.1Each hardware Order will identify the model, quantity, nominal hashrate, power assumptions, new, used or refurbished condition, price, inclusions, warranty, testing arrangements, shipment terms and estimated delivery. Operating tolerances must be disclosed or established by the applicable manufacturer specifications.
6.2Approved special procurement and pre-orders may create binding supplier commitments. Any permitted Client cancellation is handled under clause 5.2. BitHash will not supply a substitute model, change the quantity or materially alter the agreed specifications without the Client's written approval.
6.3Delivery dates are estimates unless expressly agreed as binding. The Order will allocate responsibility for shipping, customs, duties, insurance and clearance. BitHash will promptly notify the Client of a material delay and provide available supporting information. A supplier delay or default does not, by itself, constitute force majeure.
6.4Title to hardware sold by BitHash passes after full cleared payment, to the extent lawful. Risk passes at the delivery point specified in the Order; if none is specified, on physical receipt by the Client or its nominated hosting facility. Client-owned equipment delivered for hosting remains the Client's property. Delivery condition and serial numbers should be recorded.
6.5Clients should report visible delivery damage, shortages or dead-on-arrival faults within seven calendar days, preserve packaging and permit reasonable inspection. This evidence period does not exclude latent defect, warranty or mandatory consumer rights. Manufacturer warranties apply on their actual terms and commencement date. BitHash will facilitate valid claims and remains responsible for its own seller obligations that law does not allow it to exclude.
6.6Where BitHash acts as a sourcing agent rather than seller, the Order must expressly identify that role, the supplier or process for identifying it, procurement authority, disclosed commission or fee, responsibility for importation, and who holds supplier warranty and refund rights. Unless that agency structure is expressly agreed, describing a sale as sourcing does not remove BitHash's seller obligations. Manufacturer or supplier responsibility does not exclude obligations BitHash itself undertakes.
6.7The Order must distinguish ready stock from reserved stock, pre-order or special procurement and specify the dispatch or deployment prerequisites. Testing reports will identify the relevant units or batch, test date, duration, operating conditions and disclosed tolerances. A short-duration test is evidence of condition at that time, not a guarantee of future mining returns. Material substitutions require the approval in clause 6.2.
7 Repairs and maintenance
7.1Diagnostics, deep cleaning, repairs, replacement parts and return logistics are charged only as agreed. BitHash will obtain approval for work exceeding the approved budget. Diagnostic fees may apply even where repair is uneconomic if disclosed beforehand. No particular repair outcome or manufacturer approval is implied.
7.2Any workmanship warranty and parts warranty must be identified in the repair Order. Unrelated defects, misuse, liquid damage, unapproved modifications and ordinary wear are excluded only to the extent they cause the relevant failure. Removed parts are returned on request where practicable unless exchanged under an approved supplier programme. Repair access, firmware changes and data loss risks must be disclosed where material.
7.3Repair intake will record equipment identity, reported symptoms, visible condition, authorised diagnostic scope and any relevant settings. After authorised work, BitHash will provide a work summary identifying material parts replaced, test results and any agreed warranty. Client approval is required before paid work beyond the authorised scope or budget; silence is not approval. Where repair is uneconomic or unsafe, the parties will agree return, further work or lawful disposal.
8 Hosting operations, equipment and billing
8.1The Order will specify the hosting scope, permitted load, facility or geographic region, tariff, minimum term, deposit, commencement date and applicable SLA and support commitments. A 24-hour deployment commitment applies only if expressly agreed. Unless the Order provides otherwise, its period starts when BitHash has received compatible operational hardware, required cleared payments, executed documents and valid pool and wallet instructions, completed applicable compliance checks and confirmed available capacity.
8.2BitHash will exercise reasonable skill and care in providing the agreed power, cooling, connectivity, monitoring and support. Hosting does not transfer hardware ownership or ownership of mining rewards. Clients select and control their pool and payout wallet unless the Order provides otherwise. BitHash may not redirect rewards for its own benefit.
8.3Electricity is billed on measured consumption at the agreed metering boundary unless the Order expressly adopts another lawful billing basis. Any fixed capacity charge, minimum commitment, shared cooling allocation, transformer losses or ancillary consumption must be expressly disclosed and agreed. BitHash will retain supporting records and explain calculations on reasonable request. Estimates used during a meter fault must follow a documented, reasonable method and be reconciled when reliable data becomes available. Unconsumed energy will not be represented as measured consumption; separately agreed fixed or capacity charges remain governed by the Order.
8.4BitHash may apply security updates, protective power limits or emergency settings needed to prevent damage. Material overclocking, warranty-affecting changes or profit-altering firmware require written approval. Client modifications, malware, unsafe equipment and interference with other clients are prohibited. The Client must supply lawful, safe, compatible equipment and accurate technical details.
8.5Safety requirements, utility directions, emergency maintenance or genuine grid constraints may require shutdown or curtailment. BitHash will take reasonable steps to mitigate the impact and notify the Client as soon as reasonably practicable. Planned maintenance will be notified in advance where practicable. The applicable SLA determines whether downtime qualifies for a credit or exclusion. Third-party involvement does not, by itself, excuse a breach by BitHash.
8.6Facility access is controlled for security. Clients have no unrestricted right to enter secure hosting areas. Inspection, collection and reasonable ownership verification will be arranged through supervised procedures. BitHash may relocate equipment to a comparable compliant facility at its cost where reasonably necessary, with notice where feasible; relocation cannot increase agreed fees or materially reduce agreed service without consent.
8.7Clients should maintain suitable equipment and business interruption insurance. Hosting fees do not include insurance unless expressly stated. BitHash will not represent that assets are insured without identifying actual coverage. A lack of Client insurance does not excuse BitHash's own legal liability.
8.8Equipment intake, material relocation and release will be supported by an inventory recording serial numbers or another reliable identifier, quantity and reasonably observable condition. Clients will have a reasonable opportunity to notify discrepancies. Mixed or replacement units will remain traceable to the relevant owner; no substitution of a Client's equipment is permitted without authority. Collection requires proportionate identity and authority verification, with a signed or authenticated release record.
8.9Unless expressly ordered, hosting does not include pool management, wallet custody, overclocking, replacement hardware, spare parts or insurance. An approved repair, spare-unit programme or firmware change must state charges, ownership and any effect on warranty or SLA measurement. A support response target measures acknowledgement or initial technical response, not guaranteed resolution, unless a resolution commitment is separately agreed.
9 Service levels and credits
9.1Contractual uptime, hashrate availability and response commitments are those expressly incorporated into the Order. The SLA will specify the measurement period, data source, calculation method, excluded events, maintenance allowance, reporting arrangements and credit formula and cap. General website statistics are not contractual guarantees unless expressly incorporated, without limiting rights arising from actionable misrepresentation or mandatory disclosure duties.
9.2Facility availability, machine health and pool-reported effective hashrate are different measures. Pool variance, rejected shares and faulty client hardware affect rewards independently of facility uptime. Operational records are evidence, not irrebuttable proof; clients may challenge demonstrable errors.
9.3The Client should submit a service credit request within thirty calendar days of the relevant report, subject to mandatory rights. BitHash will investigate and explain its decision. Agreed service credits are the exclusive contractual monetary remedy for ordinary SLA shortfalls only. This does not exclude equipment damage claims, mandatory remedies, liabilities preserved by clause 16.4 or termination for an uncured material breach. The same loss may not be recovered twice.
9.4Schedule B governs how the SLA must be specified and evidenced. It does not create an uptime percentage, hashrate guarantee, support response time or monetary credit unless the accepted Order or SLA supplies that commitment. Any excluded event must fit the agreed definition, be supported by reasonable records and be applied only to the affected equipment, service and period. The same downtime cannot be excluded twice.
9.5If an SLA credit is due, it will be recorded against the affected service and applied on the next practicable invoice unless the SLA requires payment or another method. A credit remaining on final termination will be included in reconciliation subject to lawful set-off. Credits do not excuse accurate electricity billing or permit charging unconsumed energy as measured consumption. Persistent or material service failure remains subject to clause 10 and mandatory remedies.
10 Suspension and termination
10.1BitHash may suspend affected services immediately where reasonably necessary for safety, credible fraud or unlawful activity concerns, failed mandatory compliance checks or binding authority directions. For overdue undisputed payment or remediable non-emergency breach, it will ordinarily give seven calendar days' notice before suspension. Notice may be withheld only where legally prohibited or impracticable in an emergency.
10.2Any suspension will be proportionate and limited to the affected services where practicable. Where legally permitted, BitHash will explain the reason, identify the steps required to remedy it and restore services promptly once those steps are completed and agreed reasonable reconnection costs are paid. Accrued amounts and expressly agreed continuing fixed charges remain payable. Electricity charges remain subject to clause 8.3.
10.3Either party may terminate an affected Order for a material breach not remedied within fourteen calendar days after written notice. BitHash may terminate immediately where a serious breach cannot be remedied, provision of the service is unlawful or a binding prohibition applies. Insolvency-related termination is subject to applicable insolvency law. Unless the Order provides otherwise, BitHash may terminate for convenience on thirty calendar days' written notice, with reasonable handover assistance and reconciliation of unearned amounts under clause 5.
10.4The Order governs the minimum term, renewal, any Client right to terminate for convenience and any early termination compensation. There is no automatic renewal unless expressly agreed. If convenience termination is permitted but no notice period is specified, thirty calendar days' written notice applies. These Terms do not impose an additional early termination penalty. Any agreed compensation remains subject to applicable law, mitigation obligations and judicial adjustment where applicable.
10.5On termination, accrued sums become due, final readings and charges are reconciled, and unused deposits and advances are treated under clause 5. Rewards belonging to the Client must be accounted for and paid subject only to lawful deductions, verification and legal holds. Neither termination nor suspension transfers ownership of client assets to BitHash.
10.6A suspension does not, by itself, accelerate future unearned charges or extend the contract term. Any continuing reservation, capacity or minimum charge must be expressly agreed and lawfully due. Where the Client does not remedy a breach, BitHash will follow the agreed termination and lawful recovery process rather than automatically confiscating assets or earned rewards. Any early-exit compensation must identify its calculation basis in the Order and remains subject to clause 10.4.
11 Equipment collection and lawful recovery
11.1Clients must arrange insured collection within fourteen calendar days after BitHash confirms equipment is ready for lawful release. BitHash will provide an equipment inventory and permit reasonable verification. Documented disputed sums do not justify retention where no lawful retention right exists. Collection logistics and de-installation charges apply only if agreed.
11.2Reasonable storage fees may apply after the collection period only at a rate previously agreed or accepted in writing. BitHash remains responsible for reasonable care while equipment is held. It must make genuine attempts to contact the Client before treating property as uncollected.
11.3BitHash may exercise a contractual or statutory right to retain equipment lawfully in its possession for unpaid amounts connected with that equipment or service only to the extent permitted by law. These Terms do not dispense with any formalities, registration, owner consent or court order required to establish or enforce a security interest or right of sale.
11.4If equipment remains uncollected for sixty calendar days, BitHash may begin the lawful recovery or disposal process, giving at least thirty calendar days' final written notice identifying assets, debt and proposed action. No sale, appropriation or disposal may occur without the legal authority and approvals required. Unsafe items may be isolated and lawfully handled in an emergency.
11.5A legally authorised sale will be conducted using a reasonable method intended to achieve fair market value. BitHash will retain records and provide an itemised account. Net proceeds will be applied to lawful sale costs and amounts due, with any surplus returned to the owner. Any lawfully recoverable shortfall remains payable. Default alone does not transfer ownership of the equipment to BitHash.
11.6Equipment will be released only to its verified owner or authorised collector, subject to lawful retention rights. BitHash may require proportionate evidence to resolve conflicting ownership or collection claims and may seek directions from a competent authority. It will keep the affected assets identifiable, maintain reasonable care and avoid an indefinite hold without a lawful basis. Any agreed storage charge remains subject to clause 11.2.
12 Prohibited conduct
12.1The Client must not use the services for money laundering, terrorist financing, sanctions evasion, fraud or other unlawful conduct; provide stolen or infringing hardware; tamper with power, cooling or metering; install unauthorised firmware or hazardous equipment; access another client's systems; introduce malware; provide materially false information; or resell services without written approval. This clause does not restrict legitimate complaints, truthful reviews or reports to competent authorities.
13 Cloud hashrate services
13.1A cloud hashrate Order will specify the allocated computing power (hashrate), term, activation date, delivery measurement and tolerance, reward calculation method, each deduction, payout frequency, minimum withdrawal, network charges and remedies for under-delivery. It grants the contractual mining entitlement described in that Order and does not transfer ownership of particular machines or company equity or guarantee an investment return.
13.2Rewards must be based on verifiable mining performance and the methodology actually agreed. BitHash must maintain allocation and calculation records, avoid double allocation and disclose material deviations. Equipment or pools may change only while preserving contractual delivery and agreed risk characteristics. No unilateral change of asset or material methodology is permitted without consent except where legally required.
13.3Wallet changes require authenticated verification. Unpaid earned rewards remain a Client entitlement subject to lawful fees and holds. BitHash must not retain accrued rewards solely because a minimum withdrawal threshold remains unmet at expiry; the final balance must be settled subject to disclosed network costs and lawful processing requirements.
13.4Cloud contracts end at their agreed expiry unless expressly renewed. If mining is uneconomic, BitHash may pause or terminate early only under an expressly accepted Order mechanism describing the trigger, notice, shortfall treatment and unused prepayment reconciliation. These Terms do not authorise forfeiture of unused prepayments or recovery of deficits beyond agreed limits.
13.5Cloud hashrate services do not provide guaranteed yield or risk-free savings. Their offering and operation remain subject to clause 2.4 and any required regulatory permissions. Any separate custody or regulated payout service requires appropriate authorisation and its own lawful contractual arrangements.
13.6Each allocation and payout statement will identify the relevant period, allocated hashrate, agreed performance measure, rewards methodology, deductions, net entitlement and payment status. A hashrate entitlement is not a promise of a particular reward quantity. Clients may request reasonable supporting records relating to their own allocation, with appropriate protection for other clients and security-sensitive information. Any custody, pooled-investment or managed-return structure requires separate regulatory assessment and lawful authorisation where required.
14 Turnkey projects and operations
14.1The project agreement will define site rights, usable power, scope boundaries, capital expenditure (CAPEX), infrastructure, lease costs, electricity, O&M, permits, dependencies, milestones, procurement authority, contingencies, commissioning tests, acceptance criteria, the defects period and ongoing operations. A reservation of power capacity does not confirm energisation. Site rights, permits and power availability will be represented according to their documented status and any expressly agreed delivery obligations.
14.2Project expenditure will follow the approved budget and procurement authority. Approved, non-cancellable supplier commitments may be charged as provided in the project agreement. Scope variations and material cost changes require a written change order setting out their price and programme impact. Emergency work reasonably necessary to prevent imminent damage will be notified promptly, with supporting costs; any right to charge those costs remains subject to the Agreement and applicable law.
14.3Timelines depend on timely funding, access, design approvals, lawful site use, utilities and supplier delivery. A documented Client-caused delay extends affected dates reasonably and may justify agreed demobilisation, storage and remobilisation costs. BitHash must mitigate delays and remains responsible for obligations it expressly undertakes. Permit assistance does not guarantee authority approval.
14.4Acceptance will follow the agreed objective tests. If no procedure is specified, BitHash will issue a completion notice and test records, and the Client will have ten business days to notify specific material nonconformities. Productive use or expiry of that period without a substantiated objection may evidence acceptance only after a reasonable inspection opportunity. Minor defects will be recorded for correction and will not prevent acceptance where they do not materially impair the agreed use. Latent defect rights and mandatory remedies remain unaffected.
14.5BitHash corrects defects attributable to its workmanship during the agreed period; absent an agreed period, twelve months from acceptance applies. Manufacturer warranties apply to equipment, without excluding BitHash's mandatory obligations. Statutory structural or other non-excludable contractor liabilities are preserved. Ongoing O&M requires its own agreed scope and SLA.
14.6Title to purchased deliverables passes as agreed after payment, subject to law. Landlord rights, installed asset ownership, removal rights and lease termination consequences must be documented in the project and site agreements; these Terms do not bind a landlord or utility that has not signed them.
14.7Before a procurement or construction milestone becomes binding, the project agreement must identify required site rights, landlord consents, lawful use, utility approval and the documented status of each dependency. It must allocate which party obtains and pays for each approval and the agreed outcome if a critical condition is not satisfied by its stated deadline. A deposit or capacity reservation is not evidence of energisation, a licence or unrestricted rights over land or installed assets.
14.8The project agreement must state funding dates, milestone evidence, acceptance tests and any retention. A Client funding or approval delay permits only a reasonable, documented extension of affected activities and agreed lawful costs; unrelated work is not automatically delayed. Procurement cannot exceed authorised scope or budget without a change order, except emergency work subject to clause 14.2. A funding shortfall is not automatically force majeure or a right to cancel.
14.9A change order must identify the requested change, scope and exclusions, price and tax impact, procurement commitments, revised milestones and any SLA or warranty effect, and must be approved by authorised representatives. Completion or acceptance records must distinguish usable power and infrastructure readiness from actual miner performance and pool rewards. Acceptance does not waive notified defects, latent defect rights or mandatory contractor liability.
15 Intellectual property, confidentiality and data
15.1BitHash or its licensors retain ownership of its branding, Platform, software, methodologies, reusable designs and know-how. Subject to payment and the Agreement, the Client receives a limited, non-exclusive licence to use supplied deliverables for their agreed purpose. Ownership of Client equipment, confidential information and Client-provided data remains with the Client or the relevant rights holder. Third-party software is subject to its applicable licence terms.
15.2Clients may not copy or commercially exploit BitHash's branding, defeat platform security or access data without authority. Reverse engineering restrictions apply only to the extent lawful. BitHash may use contractors but remains responsible for its own contractual obligations; subcontracting does not by itself eliminate responsibility.
15.3Each party protects the other's non-public commercial, technical and personal information using reasonable care and uses it only for the Agreement. Disclosure is permitted to personnel, contractors and advisers with a need to know and suitable obligations, or as legally required. Publicly available, independently developed or lawfully obtained information is excluded. Confidentiality continues for three years after termination; trade secrets remain protected while confidential.
15.4Facility locations, access procedures, credentials, security layouts and other client records must not be disclosed without lawful authority. This does not prevent reporting suspected wrongdoing, consulting advisers or complying with authorities. Client names and logos may be used in public marketing only with consent.
15.5BitHash will process personal data in accordance with applicable data protection law and the Privacy Policy made available at https://bithash.ae/privacy-policy/. BitHash will identify the relevant purposes and lawful bases, provide required information about recipients and cross-border transfers, apply appropriate safeguards, retain personal data only for as long as necessary or legally required, and facilitate applicable data subject rights. Acceptance of these Terms does not constitute blanket consent to unrelated processing.
15.6Necessary disclosures may include lawful KYC providers, banks, payment processors, pools, logistics providers, insurers, advisers and authorities. Separate consent will be obtained where required, including for optional marketing. Each party must notify the other promptly of a security incident affecting the Agreement and comply with applicable regulatory notification duties.
15.7Platform statistics, mining pool data and monitoring feeds may be delayed or inaccurate. BitHash will correct verified material errors and use reliable underlying records for billing and reward calculations. Dashboard information does not override the agreed contractual methodology or reliable metering records. A monitoring interruption alone does not establish that equipment stopped mining.
15.8Blockchain forks, protocol changes, attacks, pool insolvency, rejected blocks and client wallet errors may affect mining. BitHash does not control them, but exclusions apply only to the extent the relevant loss is not attributable to its own actionable breach or failure to exercise agreed care. Client-selected third parties are the Client's responsibility except for obligations BitHash expressly assumes.
15.9For AI, HPC or other data hosting services, the parties will expressly allocate responsibility for backups, content legality, cybersecurity, personal data processing and recovery before deployment. Where required, they will enter into a separate data processing agreement. These Terms alone do not provide a guaranteed backup or data recovery service.
15.10BitHash will retain records reasonably required to perform the Agreement and meet applicable legal retention requirements, including accepted Terms, Orders, payment instructions, equipment inventories, delivery records, metering and monitoring records, approvals, service credits and reconciliations. Records containing personal data are subject to clause 15.5. Operational records remain open to correction where a material error is established.
15.11On termination, BitHash will provide reasonable access to the Client's own final inventories, metering statements, payout reconciliations and applicable completion records necessary for handover, subject to lawful holds, privacy and third-party rights. Access does not include other clients' information, protected source code or unrestricted access to secure facilities. Personal data will be handled under clause 15.5 and any applicable data processing agreement.
16 Indemnities and limitations of liability
16.1The Client indemnifies the contracting BitHash entity and its personnel against third-party claims and reasonable proven losses caused by the Client's unlawful conduct, material breach, infringement, lack of equipment ownership or unsafe equipment, to the extent attributable to the Client. Fines are recoverable only where lawful. The indemnity excludes amounts attributable to BitHash's own fault or non-excludable liability.
16.2BitHash must promptly notify the Client of an indemnified claim, permit reasonable participation in the defence and mitigate losses. No settlement imposing an admission or non-monetary obligation on the Client may be made without consent, not unreasonably withheld. Neither party receives double recovery.
16.3Subject to clause 16.4, BitHash is not liable for indirect or consequential loss, lost profits, expected mining rewards, lost opportunity, asset price movements or business interruption, whether characterised as direct or indirect, to the extent exclusion is lawful. Expressly owed rewards, refunds, price adjustments and SLA credits are not excluded by that wording.
16.4Nothing excludes or limits fraud, wilful misconduct, gross negligence, death or personal injury caused by actionable fault, mandatory consumer protections, liability for harmful acts where exclusion is prohibited, mandatory contractor liability or any liability that law does not permit the parties to exclude or limit. Any liability limitation applies only insofar as valid under applicable law.
16.5Subject to clause 16.4, BitHash's aggregate liability arising under or in connection with an affected hosting, cloud hashrate or O&M Order is limited to the service fees paid or payable under that Order in the twelve months preceding the first event giving rise to the claim, excluding taxes and separately identifiable pass-through utility or hardware charges. For a hardware sale, repair or turnkey project, the cap is the total contract price of the affected Order. Claims arising from the same or related events share one applicable cap, which is not multiplied by the number of claimants or legal grounds.
16.6Obligations to return Client-owned equipment, account for earned Client rewards, refund unused deposits or advances properly due and pay agreed credits are not extinguished by the cap. A damages claim for loss of equipment remains subject to clause 16.4 and the applicable lawful cap. Each party must mitigate its loss.
16.7Claims lie against the contracting entity; no personal recourse arises merely from a person's role as director, employee, shareholder or representative. This does not protect anyone from their own fraud, independently actionable wrongdoing, statutory liability or an express personal guarantee. These Terms do not prevent lawful interim relief, specific performance or proceedings required to preserve rights.
16.8Implied terms and warranties are excluded only to the extent permitted by law. Services remain subject to express contractual commitments and applicable duties of care. No general disclaimer overrides an agreed deliverable or mandatory warranty, and these Terms do not shorten statutory limitation periods.
16.9A party seeking compensation must identify the relevant obligation, event and loss and provide reasonably available evidence, subject to applicable burdens of proof and mandatory procedures. Parties will take reasonable steps to prevent further loss and preserve relevant records. Claim notification is encouraged promptly after discovery; no contractual reporting period in these Terms shortens a statutory limitation period or excludes a mandatory remedy. No category of claim bypasses clause 16.4.
17 Force majeure and changes in law
17.1A party is excused from an affected obligation only to the extent its performance is prevented or delayed by an event beyond its reasonable control that it could not reasonably avoid or overcome. Qualifying events may include extraordinary natural disasters, war, binding government restrictions and exceptional utility failures. Routine maintenance, foreseeable operating temperatures, lack of funds, unsuccessful fundraising, ordinary market movements and avoidable supplier problems do not, by themselves, constitute force majeure.
17.2The affected party will notify the other promptly, explain the impact, take reasonable mitigation measures and resume performance as soon as reasonably practicable. Accrued payment obligations remain payable. Charges during interruption, including any expressly agreed non-hashing relief or fixed capacity commitments, are governed by the Order and mandatory law. Force majeure does not, by itself, entitle either party to retain unearned payments.
17.3If the affected service remains substantially prevented for sixty consecutive calendar days, either party may terminate that portion on written notice, subject to final reconciliation and lawful treatment of documented commitments. Mandatory hardship or judicial adjustment powers remain unaffected. New legal restrictions may require lawful suspension, variation or termination with notice where permitted.
18 Changes, notices and complaints
18.1BitHash may publish revised Terms for future Orders. Material changes to an existing Order require agreement unless an expressly accepted mechanism or mandatory law permits the change. For a permitted material change, BitHash will ordinarily give at least thirty calendar days' notice; urgent changes required for lawful security or regulatory reasons may take effect sooner. Publication on the website alone does not amend agreed prices, refund rights or liability provisions.
18.2Formal notices to BitHash must be sent to info@bithash.ae, marked "Legal Notice", or delivered by courier to BitHash Limited at the registered address in clause 1.1, marked "Legal Notice". Any additional notice requirements expressly stated in the Order also apply. Client notices go to the recorded contractual email or address. Email is received on the next business day after successful delivery without a failure notification; courier notice is received on recorded delivery. Actual receipt controls if earlier. Update contact details promptly.
18.3Complaints may be sent to info@bithash.ae. BitHash aims to acknowledge within three business days and give a substantive response within thirty calendar days, explaining any extension. This process does not restrict reporting to authorities or statutory rights. Support contact: +971 58 572 2898. Business day means Monday to Friday excluding UAE public holidays unless the Order states otherwise.
18.4Routine service tickets and operational messages do not replace formal notices where the Agreement requires them, except where actual receipt and applicable law establish a valid notice. Notices should identify the Order, relevant facts, requested action and any applicable cure date. Formal notices, complaints and requests to preserve records may be submitted without first exhausting ordinary support channels. Nothing prevents a lawful report to authorities.
19 Governing law and disputes
19.1Unless a signed Order expressly provides a different valid governing law and forum, the Agreement is governed by the federal laws of the United Arab Emirates and applicable laws of the Emirate of Ras Al Khaimah. The competent courts of Ras Al Khaimah have exclusive jurisdiction to the extent legally permitted; mandatory jurisdiction and consumer rights prevail.
19.2The parties will seek to resolve a dispute in good faith for thirty calendar days after written notice before commencing substantive proceedings, where practicable. This does not prevent urgent interim relief, action to preserve a claim or debt, or compliance with mandatory procedures. These Terms do not independently create an arbitration agreement. Any arbitration arrangement must be expressly agreed in a legally valid written agreement by appropriately authorised representatives.
20 General provisions
20.1The Agreement is the complete agreement for its subject matter, subject to legally binding representations, mandatory disclosure duties and fraud remedies. Failure or delay to enforce a right is not a waiver. Invalid provisions are severed or adjusted only to the extent law permits, without removing mandatory rights.
20.2The Client may not assign the Agreement without consent, not unreasonably withheld for a suitable successor. BitHash may assign receivables lawfully; transfer of performance obligations requires any consent mandated by law and cannot materially reduce Client protections. No partnership, employment, fiduciary relationship or general agency is created merely by these Terms.
20.3Payment, reconciliation, ownership, lawful recovery, confidentiality, intellectual property, indemnity, liability and dispute provisions survive to the extent relevant. Third parties acquire no contractual enforcement right except where expressly agreed and legally effective.
20.4The English text governs the parties' interpretation to the extent permitted by law. Arabic information, contracts or translations will also be provided where legally required. Mandatory rules concerning consumer information, court language and the controlling text of legislation prevail.
20.5A Client's consumer status is determined by applicable law and the actual transaction, not solely by its company form, the size of an Order or a label in these Terms. Mandatory consumer information, invoice, warranty, Arabic-language and remedy requirements prevail where applicable. No purported business-use acknowledgement waives a mandatory right. BitHash will provide required information in the legally required language before acceptance.
20.6Time is measured in the UAE time zone, UTC+4, unless the Order states otherwise. Calendar days include weekends and public holidays; business days have the meaning in clause 18.3. A notice-based cure or objection period starts on the day after receipt unless mandatory law or the Order states otherwise. References to writing include authenticated electronic records where legally valid. Headings aid navigation and do not change the operative provisions.
Schedule A | Order particulars and acceptance
A1Identity and documents
Identify the contracting BitHash entity and licence details, Client legal name and contact address, legal status and authorised representative, Order reference and date, Terms version 2.3, incorporated SLA and schedules, formal notice contacts and commercial approvers. Include the licensing authority and other disclosures required by applicable law.
A2Common commercial particulars
State service scope and exclusions; prices and currency; tax treatment; payment milestones and due dates; authorised payment instructions and verification procedure; each deposit or advance category and earning trigger; invoice cycle; term and renewal; cancellation and early-exit rights and calculation basis; handover and collection charges; and any agreed insurance. Identify conditions precedent, their deadlines and the consequences if they are not satisfied.
A3ASIC sale or sourcing
State seller or expressly agreed agency role; manufacturer, model, quantity, condition and nominal hashrate; power assumptions and tolerances; ready-stock or pre-order status; testing arrangements; inclusions; dispatch estimate or binding deadline; shipping term and named destination; customs, duty, insurance and clearance allocation; title and risk transfer; actual warranty terms; and applicable cancellation commitments. If Incoterms are used, identify the rule, edition and named place.
A4Air or hydro hosting
State facility or geographic region, cooling type, equipment inventory, permitted load and compatibility, usable power, commencement prerequisites, metering boundary, tariff and included costs, shared-load allocation, fixed capacity or minimum charges if any, minimum term, security deposit, pool and payout arrangements, SLA, support channels, approved maintenance, insurance status and collection procedure. Identify what a deployment or online commitment measures and when its clock starts.
A5Cloud hashrate
State allocated hashrate and algorithm, term, activation, performance measurement and tolerance, allocation method, pool/reward methodology, each deduction, payout asset and frequency, authorised payout address, withdrawal/network charges, under-delivery remedies and final settlement. Include any expressly agreed uneconomic-mining trigger, suspension rights and unused prepayment treatment. A fixed-yield or regulated structure is not authorised by these Terms.
A6Repairs and maintenance
State intake identity and condition, reported fault, diagnostic scope and fee, authorised budget, parts approval procedure, target or binding completion period, testing, workmanship and parts warranties, removed-parts treatment, data/firmware risks, collection and agreed storage charges. Identify any manufacturer-authorised status accurately.
A7Turnkey projects and O&M
State documented site rights and lawful use, usable power and energisation status, landlord/utility consents, responsibility for permits, design and scope boundaries, CAPEX and contingencies, lease and operating costs, approved procurement authority, funding dates, milestone evidence, dependencies and critical deadlines. Specify change orders, commissioning tests, acceptance criteria, defects period, installed-asset ownership and removal, lease termination effects, handover, O&M scope and SLA. Identify any conditional takeover or refund arrangement in full.
A8AI, HPC or data colocation
State compute, rack, power, cooling and network specifications; data and access responsibilities; service measurement; security and incident duties; backups and recovery if ordered; business continuity; personal data roles and any required processing agreement; third-party licences; content legality; and exit/export arrangements. No data durability, backup or recovery guarantee arises from an unspecified service.
A9Acceptance record
The acceptance record must identify the accepted Order and Terms version, incorporated documents, authorised parties, date and valid signature or authenticated electronic acceptance. A suitable acknowledgement is: "I am authorised to accept Order [identified reference]. Before acceptance, I received and could retain BitHash Website Terms and Conditions Version 2.3 dated 3 October 2026 and the documents expressly incorporated into that Order. I accept those documents and the commercial particulars stated in the Order." The Order reference must be completed in the acceptance record. This acknowledgement does not waive mandatory rights or bind a person who lacks legally sufficient authority.
Schedule B | SLA specification and evidence
B1Define the service and target
Identify each affected service or equipment group, measurement period, time zone, contracted target, whether the metric is facility availability, machine availability or delivered hashrate, and any support response or resolution target. Annual and monthly targets are different commitments and must not be substituted for each other.
B2Availability calculation
Where minute-based availability is adopted, define scheduled service minutes, excluded minutes and eligible downtime minutes for the same measurement period and affected service. Eligible minutes equal scheduled minutes less expressly agreed excluded minutes. Availability percentage equals 100 multiplied by (eligible minutes less eligible downtime minutes), divided by eligible minutes. If eligible minutes are zero, report the metric as not measurable for that period and apply the agreed treatment; do not report artificial 100% availability. Fleet aggregation and partial outages require an agreed weighting method.
B3Hashrate calculation
Specify nominal or contracted hashrate, averaging window, accepted data source, delivery tolerance, partial-delivery calculation and exclusions. State how rejected shares, pool variance, Client hardware faults and curtailment are treated. Pool effective hashrate and facility availability must be reported separately where relevant. A temporary monitoring outage is not automatically a mining outage, but alternative evidence must support the actual performance claimed.
B4Exclusions and maintenance
List each exclusion and its boundary, including any approved maintenance allowance, Client-caused failure, lawful curtailment or qualifying force majeure. Identify how much planned maintenance may be excluded and what notice is required. Exclude only events within the agreed definition and only the affected duration and service. Subcontractor or utility involvement alone is not a blanket exclusion. Concurrent events cannot create duplicate excluded time.
B5Evidence and reports
Specify meters, monitoring feeds, incident logs and other records used, report delivery timing, treatment of gaps and corrections, and the process for reconciling competing data. BitHash will preserve reasonably available incident and calculation records under clause 15.10 and provide relevant supporting information on reasonable request, subject to privacy and facility security. Neither party's data is automatically conclusive.
B6Credit basis and limits
Specify the eligible service fee component, target shortfall bands or formula, credit rate, cap, claim timing and application method. State whether taxes, hardware and separately billed utilities are excluded from the credit base. Credits must relate to the affected service and period and cannot exceed the agreed lawful cap. This Schedule creates no monetary credit formula where none is agreed. Clause 9.3 preserves mandatory and other expressly reserved remedies.
B7Claim and decision procedure
A request should identify the Order, affected units or service, incident dates, claimed metric and reasonably available evidence. The thirty-calendar-day request period in clause 9.3 remains subject to mandatory rights. A deadline will not run before the relevant report is provided. BitHash will investigate, explain the calculation and exclusions, and correct substantiated errors. The SLA should state an acknowledgement and decision timetable; the complaints process in clause 18.3 remains available.
B8Support, restoration and escalation
Define the support channel, hours and severity criteria, when a response clock starts, and any agreed pause while reasonably necessary Client information or access is awaited. A pause must be documented and cannot conceal BitHash-caused delay. Response, restoration and final resolution are separate measures. Identify escalation contacts, report frequency and any repeated-failure termination trigger. Without an express trigger, material breach is handled under clause 10.3.
B9Billing and termination
Downtime credits, electricity consumption adjustments and reconciliation of fixed charges are different calculations. Apply each according to the Order and clauses 8 to 10, without double recovery or fictitious consumption. Final credits and unearned prepayments must be accounted for on termination. No SLA provision authorises retention or disposal of equipment without the lawful process in clause 11.