[$ ] legal: refund

1. Scope

This Refund Policy governs the operator’s obligation to refund payments received in XMR for Services supplied under the XMRHost brand. It is incorporated into the Terms of Service (/legal/tos) by reference. Where this Policy conflicts with the Terms, the Terms prevail; where this Policy is silent, the Terms apply by default.

The headline structure of refund availability is:

1. A 7-day no-questions-asked refund on a Customer’s first-ever invoice across the Account (§2).
2. A pro-rata refund where the operator materially modifies a Service’s technical spec on a forward-only basis and the Customer elects to terminate (§3, cross-referenced from TOS §4).
3. A pro-rata refund where the operator’s SLA breach in a given month exceeds the credit-ladder credit and the Customer elects to terminate (§4, cross-referenced from /legal/sla §4).
4. No refund on the AUP-suspension or the legal-compulsion class (§5).
5. The Customer’s general right of termination for convenience under TOS §7.5 with the first-invoice-cycle pro-rata refund.

2. First-invoice no-questions refund

A Customer may request a full refund of the first-ever invoice paid against the Account, no questions asked, within seven (7) calendar days of the invoice payment timestamp recorded by the operator’s payment-watcher (the timestamp at which the first XMR confirmation on the keyed subaddress crossed the operator’s confirmation threshold — see /payments for the threshold). The window is not extended by partial use of the Service or by the Service-instance being non-operational during the window.

This refund is available only on the Account’s first-ever invoice. Subsequent invoices, including renewal invoices on the same Service, are subject to §3 / §4 / TOS §7.5 only. The first-invoice refund does not require the Customer to identify a defect in the Service or to articulate a reason; the only required information is the Account identifier and the on-chain transaction reference of the original payment.

Where the Customer exercises the first-invoice refund, the Service is terminated effective the timestamp of the refund request (TOS §5.4 wipe semantics apply). The XMR refund is dispatched per §6 mechanics within 14 calendar days of the request.

3. Operator-initiated spec modification

Per TOS §4, the operator reserves the right to modify the technical specification of a Service tier on a forward-only basis with at least 30 days’ notice. Where the modification is material and adverse to the Customer (e.g. CPU model downgraded by more than one generation, RAM clock reduced by more than 20%, disk technology downgraded from NVMe to SATA, network upstream reduced by more than 25%), the Customer may elect to terminate the affected Service and receive a pro-rata refund of the unused portion of the current invoice cycle.

The pro-rata calculation is straightforward — refund = (cycle invoice amount in fiat) × (days remaining in cycle / total days in cycle), converted to XMR at the §6 conversion convention. The Customer’s election must be communicated to the support mailbox within 14 calendar days of the operator’s modification notice; an election made after the 14-day window forfeits the pro-rata refund right (the Customer may still terminate for convenience under TOS §7.5 but without refund).

4. SLA-breach refund

Where, in a given calendar month, the operator’s SLA breach on a Service-instance is severe enough that the Service Credit ladder in /legal/sla §4 caps out at 100% of the monthly invoice — i.e. the Monthly Uptime Percentage falls below 90.0% for VPS / dedicated / GPU tiers, or below 80.0% for Tor / I2P / Lokinet tiers — the Customer may, in addition to claiming the 100% Service Credit per /legal/sla §7, elect to terminate the affected Service and receive a pro-rata refund of any pre-paid future invoice cycles. The pro-rata calculation matches §3 above, applied to the full pre-paid balance from the date of termination forward.

The Customer’s election under this clause must be communicated within 30 calendar days of the end of the affected month, in the same window as the credit-claim under /legal/sla §7. The two remedies are cumulative — the Service Credit covers the breach month; the pro-rata refund covers the unused future cycles.

5. Categories with no refund

No refund is available where:

5.1. AUP suspension

The Service has been suspended or terminated for breach of the Acceptable Use Policy under TOS §7.2 / /legal/aup. The Customer’s pre-paid invoice for the suspended cycle is forfeit; the operator’s enforcement cost on the AUP path is the implicit liquidated-damages floor.

5.2. Legal compulsion

The Service has been suspended or terminated under TOS §7.3 in compliance with a binding court order from an Operating Jurisdiction’s court. The Customer’s pre-paid invoice for the suspended cycle is forfeit. The Customer’s recourse against the underlying compulsion is against the issuing court, not against the operator.

5.3. Non-payment

The Service has been terminated under TOS §5.4 for non-payment. There is by definition no balance to refund — the Customer did not pay.

5.4. Charge-back attempt

There is no charge-back surface in Monero (the protocol is settlement-final). The operator does not entertain payment-reversal requests channelled via any other route — there is no fiat rail, no card processor, no PayPal account through which a charge-back could be initiated. The Refund Policy in this document is the sole avenue for payment reversal.

6. Refund mechanics

All refunds are dispatched in XMR. The operator does not refund in fiat, does not refund in any other crypto-asset, and does not refund into a custodial account.

6.1. Customer-supplied refund subaddress

To initiate a refund, the Customer submits a refund-destination XMR address to the operator via the refund-request ticket. The operator strongly recommends the Customer supply a fresh subaddress dedicated to the refund (i.e. a subaddress not previously used on-chain for any other purpose), to avoid the refund being correlated with the Customer’s other on-chain activity. The operator’s instance of monero-wallet-cli will dispatch to whatever address the Customer supplies, but the on-chain privacy posture is the Customer’s responsibility once the address is supplied.

6.2. Conversion-rate convention

For refunds whose underlying calculation is in fiat (the §3 spec-modification pro-rata, the §4 SLA-breach pro-rata, and the §2 first-invoice refund where the original invoice was billed in fiat-equivalent), the XMR amount payable is computed at the spot rate published by Kraken-XMR/USD at 12:00 UTC on the date the refund is approved. The operator does not adjust for spot-rate movement between the original payment and the refund — the Customer carries the price-volatility risk on the holding period.

For refunds whose underlying calculation is in XMR (e.g. a Customer who paid in XMR and is requesting a refund of the XMR amount actually paid), the operator dispatches the same XMR amount as was originally received, less any on-chain transaction fee. There is no fiat-conversion step in this case.

6.3. View-key issuance

The Customer may request the operator’s view-key for the refund subaddress under the same protocol as for invoice payments (see /payments). Upon request, the operator dispatches the per-subaddress view-key over PGP-encrypted email to the Customer’s registered (or PGP-supplied) public key. The Customer can then use any standard Monero-wallet-CLI invocation to verify the inbound transaction and the operator’s per-subaddress balance independently.

6.4. Settlement timeline

Refunds are dispatched within 14 calendar days of approval. The 14-day window covers operator-side internal processing (claim validation, per-§6.2 conversion-rate computation, on-chain dispatch, mempool confirmation). On-chain confirmation timing depends on the Monero network’s block-cadence (~2 minutes per block); the operator considers a refund settled at 10 confirmations.

7. Procedural surface

Refund requests are submitted via the legal mailbox (for §2 first-invoice and §3 spec-modification refunds) or the support mailbox (for §4 SLA-breach refunds and §6.4 settlement-timing enquiries) listed under /legal DISPATCH. The submission must include:

• The Account identifier;
• The Service-instance identifier (where applicable);
• The on-chain transaction reference of the original payment;
• The §6.1 refund subaddress;
• The basis of the refund request (which §2 / §3 / §4 / TOS §7.5 path is being invoked);
• For §3 / §4 requests, the supporting evidence (the operator’s modification notice or the Customer’s MUP measurement, as relevant).

The operator acknowledges receipt within 48 hours and approves or rejects the request within 14 calendar days of substantively-complete submission. Disputes are processed under TOS §11.

8. Double-recovery exclusion

A refund under this Policy is the Customer’s sole financial remedy for the underlying basis of the request — the Customer is not entitled to recover the same amount under any other heading (the §4 SLA-breach refund is in addition to the Service Credit per §4 above, but the two remedies are exhaustive of the Customer’s monetary recovery for that specific MUP shortfall). A refund under §2 / §3 / §4 / TOS §7.5 fully discharges the operator’s payment-reversal obligation in respect of the invoice cycle to which it applies.

9. Updates

This Policy is updated to reflect (a) changes in the operator’s payment surface (e.g. the addition of a non-XMR settlement rail — not anticipated at MVP, but the §6 mechanics would need extension), (b) changes in Operating-Jurisdiction tax law that affect the §6.2 conversion convention, or (c) procedural refinements. Material updates are effective on the effectiveFrom date with at least 30 days’ notice; non-material clarifications take effect immediately on publication.