[$ ] legal: tos

1. Definitions

For the avoidance of definitional drift, the terms below are used throughout this document with the meanings here. Capitalisation is informational, not normative — the term has the same meaning whether or not it is capitalised in body text.

• Operator — the legal entity that procures the upstream hosting capacity, operates the XmrCloud brand surface, holds the customer relationship, and to which payments are made. The operating entity and its jurisdiction of incorporation are listed on /legal under the operator-disclosure block. Until counsel filing is complete, both fields render TBD.
• Customer — the natural or juridical person that registers a XmrCloud account, accepts these Terms, and pays for one or more Services.
• Service — any of the hosting products listed under /node/<type> (vps, dedicated, gpu, tor-hidden-service, i2p-node, lokinet-exit). The Service definition includes the underlying compute, the network egress allotment, the IPv4 / IPv6 address assignments, and any add-ons explicitly attached to the order.
• Account — the identity record created at sign-up, against which Services are provisioned and invoices are issued. Accounts are pseudonymous by default; see the Privacy Policy (/legal/privacy) for what is collected.
• AUP — the Acceptable Use Policy at /legal/aup, incorporated into these Terms by reference.
• SLA — the Service Level Agreement at /legal/sla, incorporated into these Terms by reference.
• Refund Policy — the Refund Policy at /legal/refund, incorporated into these Terms by reference.
• Operating Jurisdiction — Iceland or Romania, in either case the jurisdiction in which the upstream datacenter housing the Service is located. The Customer chooses the jurisdiction at order time per /location/<code>.
• XMR — the Monero protocol token. The sole accepted payment instrument; see /payments and /why-monero for the operator’s stance.

2. Scope and acceptance

These Terms govern the supply of every Service the operator makes available under the XmrCloud brand. A Customer accepts these Terms by either (a) clicking the [ accept ] control on the order confirmation page, or (b) paying the first invoice for any Service. Acceptance binds the Customer to the version of these Terms in force at the time of acceptance; subsequent revisions take effect on the effectiveFrom date listed in the front-matter of the revised document, with at least 30 days’ notice via email to the Account contact for material changes.

The Customer must be either a natural person aged 18 or older or a juridical person duly constituted under the laws of its jurisdiction of organisation. The operator does not collect documentary proof of either condition; representations to that effect at sign-up are taken at face value.

3. Account terms

The Customer is responsible for maintaining the confidentiality of the Account credentials, including the password, any API tokens, and any SSH keys uploaded for VPS provisioning. The operator does not store passwords in cleartext (PBKDF2 / Argon2id per the active password schema) and does not log API tokens after their initial issuance. The operator does not have a recovery path for a forgotten password that bypasses the registered email — see /legal/privacy for the email-collection rationale.

The Customer is responsible for all activity carried out under the Account, including activity by the Customer’s employees, agents, and any third parties to whom the Customer voluntarily grants access. Account-sharing is permitted; the operator does not enforce a one-natural-person-per-account rule.

The Customer must register a contactable email address and keep it up to date. The operator’s binding-notice channel is that email address; operational alerts (invoice due, SLA-credit issuance, suspension notice, AUP enquiry) are routed there. If the email bounces for more than seven (7) consecutive days, the operator may suspend the Account pending re-establishment of a working contact.

4. Service scope

The operator agrees to supply the Service ordered by the Customer, in the quantity and configuration set out in the order, for the term invoiced. The Service is supplied on a best-effort basis subject to the SLA at /legal/sla. The operator does not warrant fitness for any particular purpose other than the technical specification published on the relevant /node/<type>/<id> page at the time of order.

The Customer’s installed software, configurations, and data on the Service are the Customer’s responsibility. The operator does not back up the Service unless a backup add-on is explicitly part of the order; for the data-loss exposure see /docs/backup-and-restore (forthcoming).

The operator reserves the right to modify the technical specification of a Service tier (CPU model, RAM clock, disk technology, network upstream) on a forward-only basis with at least 30 days’ notice. A Customer whose order is materially impaired by such a modification may terminate the affected Service for a pro-rata refund per /legal/refund.

5. Payment

5.1. No-KYC crypto only. All Services are billed in crypto-asset only — Monero (XMR), Bitcoin (BTC, on-chain and Lightning), Litecoin (LTC), Ethereum (ETH), and Tether (USDT on ETH / Polygon / Tron) are the accepted rails as of this revision; the operator may add or remove rails in the OxaPay merchant dashboard on a forward-only basis. The operator does not accept fiat, does not run a card processor, and does not accept payment via any custodial intermediary that would surface a KYC chain. Monero is the recommended rail for chain-analytics-aware threat models; the editorial rationale is at /why-monero and /payments.

5.2. Per-order subaddresses (XMR rail). When the Customer pays in XMR, each invoice is keyed to a unique subaddress derived from the operator’s view-key-public master under standard Monero subaddress semantics. The Customer may request the operator’s view-key on demand to verify receipt of payment to the keyed subaddress; see /payments for the issuance protocol. Other rails do not carry an equivalent operator-side privacy primitive — the chain-analytics trade-off is the Customer’s choice when selecting a non-XMR rail.

5.3. Invoice cycles. Invoices are issued monthly, quarterly, semi-annually, or annually at the Customer’s selection at order time. The fiat-equivalent billing rate (USD-denominated) is fixed at order time for the duration of the cycle; the crypto amount due on each invoice is computed at the spot rate published by the OxaPay processor at invoice-issue date.

5.4. Payment window. An invoice is payable within seven (7) calendar days of issuance. After day 7 the Service enters a grace state (full functionality, recurring email reminders); after day 14 the Service enters a suspended state (read-only or powered-off at the operator’s election); after day 30 the Service is terminated and the data is irreversibly destroyed per a single-pass DoD 5220.22-M wipe (or equivalent on the underlying storage medium).

5.5. No charge-backs. Crypto rails are settlement-final protocols; there is no charge-back surface on any accepted rail (XMR, BTC, LTC, ETH, USDT). The Refund Policy at /legal/refund is the sole avenue for payment-reversal.

6. Acceptable use

The Customer’s use of the Service is governed by the AUP at /legal/aup, which is incorporated into these Terms by reference. A breach of the AUP is a breach of these Terms. The operator’s enforcement posture is set out in the AUP itself; there is no separate enforcement procedure under these Terms.

7. Suspension and termination

7.1. Suspension for non-payment. Per §5.4 above.

7.2. Suspension for AUP violation. The operator may suspend a Service immediately upon receipt of a credible AUP-violation report under the AUP’s specifically-enumerated hard-prohibition list (see /legal/aup §3). For all other AUP categories the operator must give the Customer at least 24 hours’ written notice and an opportunity to cure before suspending.

7.3. Suspension for legal compulsion. The operator may suspend a Service in compliance with a legally-binding order issued by a court of competent jurisdiction in an Operating Jurisdiction. The operator does not voluntarily comply with extra-territorial requests; foreign requests are processed only via the mutual-legal-assistance channel of the relevant Operating Jurisdiction. See /legal/privacy §6 for the operator’s procedural posture.

7.4. Termination for cause. Either party may terminate a Service for cause (defined as a material, uncured breach of these Terms by the other party) upon thirty (30) days’ written notice; if the breach is uncured at the end of the notice period, termination is effective. Suspension under §7.2 or §7.3 may convert to termination at the operator’s election after fourteen (14) days’ continued breach.

7.5. Termination for convenience. The Customer may terminate a Service at any time by closing the Service in /console. Pro-rata refund per /legal/refund is available in the first invoice cycle only.

7.6. Effect of termination. Upon termination, the operator’s access obligations cease, and the Customer’s data on the Service is irreversibly destroyed within seven (7) calendar days of termination per §5.4 above. The operator does not retain a backup of the terminated Service.

8. Intellectual property

The Customer retains ownership of all data, code, configurations, and content uploaded to or generated on the Service. The operator does not claim a licence over Customer content for any purpose other than the technical operation of the Service (replication to RAID, snapshot for backup if a backup add-on is enabled, transit through the operator’s ingress / egress paths).

The operator’s brand, logos, documentation prose, and code published on the XmrCloud surface are the operator’s intellectual property and are licensed under the terms set out at /legal/aup §6 (open content) where applicable; nothing in these Terms grants the Customer a licence over those assets.

9. Liability

9.1. Cap. The operator’s aggregate liability to the Customer under these Terms, in respect of any Service, is capped at the total amount paid by the Customer for that Service in the twelve (12) months preceding the event giving rise to the claim. This cap applies to the maximum extent permitted by the law of the relevant Operating Jurisdiction.

9.2. Exclusions. The operator is not liable for indirect, consequential, special, or punitive damages, or for lost profits, lost data (subject to the §4 backup posture), lost opportunity, or business interruption, arising out of or in connection with these Terms or the Service.

9.3. Carve-outs. Nothing in this clause excludes or limits liability for (a) the operator’s gross negligence or wilful misconduct, (b) personal injury or death caused by the operator’s negligence, or (c) any liability that cannot be excluded under the applicable Operating Jurisdiction’s law.

10. Force majeure

Neither party is liable for failure to perform any obligation under these Terms (other than payment) to the extent that the failure is caused by an event beyond the party’s reasonable control, including without limitation acts of God, war, terrorism, civil disturbance, governmental action (including export-control orders, sanctions, and judicial orders affecting the Service), pandemic, fibre cut affecting the Operating Jurisdiction’s transit, or upstream-provider failure. The affected party must notify the other party promptly and use reasonable efforts to resume performance.

11. Dispute resolution

11.1. Negotiation. The parties shall attempt in good faith to resolve any dispute arising out of or in connection with these Terms by negotiation between authorised representatives, for a period of at least thirty (30) days from the date a written notice of the dispute is given.

11.2. Arbitration. If negotiation under §11.1 fails, the dispute shall be finally resolved by arbitration administered by the operator’s elected arbitral institution in either Iceland or Romania, at the operator’s election made within fourteen (14) days of the receipt of the §11.1 dispute notice. The seat of the arbitration shall be Reykjavík (if Iceland) or Bucharest (if Romania); the language of the arbitration shall be English; the tribunal shall consist of a sole arbitrator unless the amount in dispute exceeds USD 100,000 equivalent at the time of filing, in which case three arbitrators shall be appointed.

11.3. Carve-out. Either party may seek injunctive or other equitable relief from a court of competent jurisdiction in an Operating Jurisdiction in support of the arbitration or to protect its intellectual property.

12. Governing law

These Terms are governed by the law of the Operating Jurisdiction selected at order time for the Service. Where multiple Services are governed by these Terms across both Operating Jurisdictions, the law of the Operating Jurisdiction in which the Service most closely connected to the dispute is located applies. [EU Rome I Regulation 593/2008] applies as a fallback for choice-of-law questions where these Terms are silent.

For Customers domiciled in the European Economic Area, mandatory consumer-protection provisions of the Customer’s habitual-residence jurisdiction (per the Rome I Regulation Article 6) apply notwithstanding the operator’s choice-of-law election above.

13. Notices

Notices to the operator must be addressed to the legal mailbox listed under /legal DISPATCH. Notices to the Customer are deemed given when sent to the Account contact email per §3 above.

14. Severability

If any provision of these Terms is held by a competent tribunal to be invalid, illegal, or unenforceable, that provision shall be modified to the minimum extent necessary to make it valid, legal, and enforceable, or if such modification is not possible, severed; the remaining provisions shall continue in full force and effect.

15. Entire agreement

These Terms (together with the AUP, SLA, Refund Policy, and Privacy Policy at /legal/aup, /legal/sla, /legal/refund, and /legal/privacy) constitute the entire agreement between the parties relating to the supply of Services and supersede any prior agreement, representation, or understanding between them. No variation of these Terms is effective unless in writing and signed (or accepted via the operator’s /console acceptance flow) by both parties.