[$ xmrhost] _

$ pwd

/payments

[$ ] payments

no-kyc multi-crypto — xmr recommended; btc / lightning / ltc / eth / usdt accepted.

// NAME

payments — xmrhost billing surface, oxapay-processor-backed, audited end-to-end.

// SYNOPSIS 

xmrhost-cli order --plan=<slug> --region=<is|ro>
xmrhost-cli pay --order=<id>                    # picks currency on the oxapay page
xmrhost-cli refund request --order=<id> --address=<addr>

// WHY MONERO IS RECOMMENDED (NOT REQUIRED)

$ grep -ri 'rationale' /etc/xmrhost/payments

The brand accepts XMR / BTC / Lightning / LTC / ETH / USDT through the OxaPay no-KYC processor. Customers pick the rail that fits their threat model: Monero is the recommended default because it closes the chain-analytics gap at the protocol layer; the other rails are convenient but leave that gap open.

The customer threat model that drives an offshore-jurisdiction host decision — subpoena, civil discovery, ex-parte preservation orders, chain-analytics correlation — is only partially defeated by where the box runs. Settlement rails leak the rest. Paying for privacy infrastructure with a transparent ledger (BTC, LTC, ETH, USDT) creates a cleartext receipt that survives the host: the lawful intercept hits the payment processor or the chain-analytics vendor, not the operator. Coin Center's brief on the August 2022 OFAC Tornado Cash designation and the 2024 follow-on filings make the point explicitly — pseudonymity on a public chain is not anonymity once heuristic clustering, exchange KYC, and address-tagging databases compose. Customers using a non-XMR rail should pay from a wallet they don't mind being tied to this purchase.

The chain-analytics literature is unambiguous on the BTC side. Meiklejohn et al., "A Fistful of Bitcoins" (IMC 2013), demonstrated multi-input + change-address heuristics that collapse most BTC wallets into clusters within months of activity. Twelve years of tooling later, services like Chainalysis Reactor and TRM Labs operate on the same primitives at industrial scale. Monero is not perfect — Möser, Soska, Christin et al., "An Empirical Analysis of Traceability in the Monero Blockchain" (FC 2018), documented pre-RingCT decoy-selection weaknesses — but the protocol has since deployed mandatory RingCT, Bulletproofs (MRL-0011), and a 16-decoy ring size, and the paper's residual heuristics no longer apply to post-2020 transactions. The reading is "Monero raises the cost of de-anonymisation by orders of magnitude", not "Monero is magic". For privacy-infra hosting that gap is enough — but the brand does not gate access to the platform on it.

// see also /why-monero — longer-form treatment of the same argument with a fuller reading list (RFC 7686 onion considerations, Monero Research Lab MRL-0001 through MRL-0011, EFF amicus filings on financial-surveillance cases). The rest of this page documents the operator-side mechanics: OxaPay processor, per-order subaddresses (XMR), view-key transparency, refund flow.

// SUBADDRESSES

$ man monero-wallet-rpc | grep -A2 'create_address'

Every xmrhost order generates a fresh Monero subaddress, derived deterministically from the operator wallet's master view-key and spend-key under a per-order index (account, address). The derivation is the standard one documented in the Monero source tree (src/device/device_default.cpp, function get_subaddress_secret_key) and in Sarang Noether's 2017 subaddress note: each subaddress is a one-way function of the master keys plus the index, and an on-chain observer cannot link two subaddresses back to the same wallet without the view-key.

Result — the on-chain footprint of an entire month of xmrhost orders looks, to chain-analytics tooling, like a fan of unrelated one-shot recipients. There is no master-address aggregation point visible publicly. The operator wallet exists, but its identity is not derivable by walking the on-chain transaction graph.

// example subaddress format (95 base58 chars, leading 8 for subaddresses; 4 for primary, 5 for integrated — format only, NOT a live address): 

order:    xmrhost-2026-05-06-01a3
plan:     tor-2
region:   is
amount:   0.74218963 XMR  (≈ $42.00 @ coingecko mid-price)
expires:  in 02h 00m

xmr:      88EXAMPLEPLACEHOLDERsubaddressNOTAREALWALLETjustForFormatDemoChars
          8ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ95chr

uri:      monero:88EXAMPLEPLACEHOLDER...?tx_amount=0.74218963&tx_description=xmrhost-2026-05-06-01a3

The monero: URI follows the unofficial-but-widely-honoured scheme used by Cake Wallet, Feather, Monerujo, and the official GUI — same shape as BIP21 for BTC. Scanning the QR or pasting the URI prefills amount + payment description without the user having to copy three fields by hand.

// VIEW-KEY TRANSPARENCY

$ monero-wallet-cli > viewkey

Monero addresses decompose into a public-spend / public-view keypair. The corresponding private view-key lets a holder scan the blockchain and identify outputs sent to that address — but spending those outputs requires the separate private spend-key, which the operator never discloses. This asymmetry is the foundation of every Monero audit workflow: a wallet can prove receipt without surrendering spend authority.

XMRHost exposes this property as an opt-in per-order audit handle. At checkout the customer ticks --audit-view-key (or its console-panel equivalent), and on payment confirmation the post-order receipt includes the private view-key for the subaddress that received the payment. The customer can then independently verify the on-chain receipt using monero-wallet-cli --view-only --restore-from-keys against any node they trust (their own, or a public one). The operator gains no information from this; the customer gains the ability to refute a "we never received your payment" claim cryptographically rather than evidentially. 

customer$ monero-wallet-cli \
    --view-only \
    --restore-from-keys ./order-01a3.viewonly \
    --address 88EXAMPLEPLACEHOLDER... \
    --view-key <hex from xmrhost receipt> \
    --restore-height <block height at order time>

# inside the wallet:
[wallet 88EX]: refresh
Height 3146210 / 3146210
Found 1 incoming transfer:
  txid:        a8f3...d219
  amount:      0.74218963 XMR
  height:      3146198
  unlock_time: 0
  tx_hash:     a8f3c4...d219

What this is: cryptographic proof of receipt for the single order in question. What this is not: a window into the operator wallet, into other customer orders, or into any address other than the one bound to the audited order. The view-key is per-subaddress, scoped to one (account, index) pair. Sharing it leaks the order; it does not leak the wallet.

// opt-in. default checkout does not generate a per-order view-key handoff — the cryptographic burden is non-zero (the operator wallet runs an extra subaddress-derivation pass and stores the per-order viewkey alongside the order record), and most customers never use it.

// REFUND MECHANICS

$ xmrhost-cli refund --help

The refund window is 7 days from order placement. Refunds are paid back in XMR to a customer-supplied subaddress, never to a xmrhost-derived destination — the customer chooses the wallet that the refund credits. The privacy property to preserve is that the refund must not create an on-chain link between the customer's funding-side wallet (which sent the original payment) and the wallet that receives the refund. Customers who care about this should generate the refund destination in a fresh wallet that has never touched the funding side; customers who don't can re-use the same wallet without complaint from us.

// STEP 1. request the refund 

customer$ xmrhost-cli refund request \
    --order=xmrhost-2026-05-06-01a3 \
    --address=88REFUNDDESTINATIONFRESHwalletYouOwnCanBeAnythingHere95chrxxxxxxxxxxxxxxxxxxxxxx \
    --reason="" # optional, free-text, never logged beyond the refund record itself

// STEP 2. operator validation (server-side, no human in the loop for in-window refunds) 

[ok] order in 7-day window (placed 2026-05-04)
[ok] order paid + confirmed (10 confirmations, finalised at height 3146198)
[ok] requested address validates as Monero subaddress (CryptoNote checksum ok)
[ok] no prior refund on this order
[ok] queued for next refund batch (twice daily at 09:00 / 21:00 UTC)

// STEP 3. refund broadcast 

[ok] tx constructed (ringsize=16, priority=normal, fee=0.00012 XMR)
[ok] tx broadcast: 9c1b...774e
[ok] receipt sent to /console; original order viewkey (if generated) revoked
[ok] refund visible to customer wallet on next refresh (~2 min)

The refund TX itself uses the same RingCT + Bulletproofs construction as any other Monero transaction — sender, receiver, and amount are private at the protocol level. The operator wallet is provably the source only to anyone holding the operator's view-key, which is not published. From a chain-analytics standpoint, the refund is indistinguishable from any other outbound TX on the network.

// partial refunds (e.g. mid-month cancellation of a multi-month plan) are pro-rated by the same script and use the same flow. Out-of-window cancellations are case-by-case — we'd rather you contacted us than ate the loss; see the legal/refund page for the policy text. Refund batching is operational, not adversarial: it amortises wallet-spend overhead and reduces the operator wallet's transaction count, which is itself a small privacy property.

// OPERATIONAL NOTES — ACQUIRING MONERO

$ apropos 'how do i get monero'

The whole point of paying with XMR for offshore privacy infrastructure is to avoid creating a chain-of-custody record that ties your real identity to the hosting purchase. That property is undermined if you acquire the XMR through a service that requires government ID, address verification, or a bank account in your name. The list below is restricted accordingly: peer-to-peer venues with no centralised KYC entity, and account-less atomic-swap brokers that take crypto in and pay crypto out.

// P2P / DEX

  • Bisq — long-running P2P trading network, runs as a desktop app over Tor. Wide payment-method coverage including cash-by-mail and SEPA. XMR pairings are smaller than BTC pairings but liquid in EUR / USD / GBP.
  • Haveno — Monero-native fork of Bisq, XMR-as- collateral. Federated network model; pick a Haveno instance you trust (haveno.exchange, RetoSwap, etc.).
  • RetoSwap and other Haveno forks — same protocol, different operator front-ends. Useful when one instance has thin order books in your jurisdiction.

// ATOMIC-SWAP / NO-ACCOUNT BROKERS

  • SideShift — crypto-in / crypto-out, no account, fixed-rate or variable-rate. Useful if you already hold another asset (stablecoins, ETH, etc.) and want to swap to XMR without touching a custodial exchange.
  • FixedFloat, Trocador, Majestic Bank, eXch — similar profile, different fee curves and liquidity. Trocador is a meta-aggregator across several of these and is convenient when you want best-execution without manually polling each.

// WALLETS

  • Feather (desktop, Qt, BSD) — lightweight, sane defaults, integrates Tor + remote-node selection. Recommended starting point for desktop users.
  • Cake Wallet (mobile, BSD) — iOS/Android, actively maintained, supports XMR + several others.
  • Monerujo (Android, GPLv3) — Android-only, long-standing community wallet.
  • monero-gui + monero-wallet-cli (official, BSD) — headless or full-GUI, runs against your own node. Correct choice for elevated threat models.

// we deliberately do not name centralised exchanges that gate Monero behind ID verification. Routing through one of those defeats the point of paying in XMR for offshore privacy hosting — the on-ramp record is the chain-of-custody record. If your only realistic option is a KYC venue, consider whether your threat model actually needs offshore privacy hosting, or whether a clearnet provider in your home jurisdiction is the honest answer.

// EXAMPLE — provision-with-monero

$ xmrhost-cli order --currency=xmr

The full transcript end-to-end — from order placement to refund eligibility — using the (mocked) XMRHost CLI surface. The console UI at /console exposes the same fields with the same names; pick whichever matches your workflow. 

$ xmrhost-cli order --plan=tor-2 --region=is --currency=xmr
[ok] resolving plan tor-2 in region=is
[ok] plan = tor-2 (2 vCPU, 4GB RAM, 50GB SSD, hardened-by-default profile)
[ok] price = $42.00 USD/mo  →  0.74218963 XMR @ coingecko mid-price (5m freshness)
[ok] order id  = xmrhost-2026-05-06-01a3
[ok] subaddr   = 88EXAMPLEPLACEHOLDERsubaddressNOTAREALWALLET95chr
[ok] uri       = monero:88EXAMPLE...?tx_amount=0.74218963&tx_description=xmrhost-2026-05-06-01a3
[ok] expires   = in 02h 00m  (re-quote available via `xmrhost-cli order requote`)

$ xmrhost-cli pay status --order=xmrhost-2026-05-06-01a3
[..] confirmations: 0/10  (tx in mempool)
[..] confirmations: 1/10
[..] confirmations: 4/10
[ok] confirmations: 10/10  → finalised at block 3146198
[ok] node provisioning queued
[ok] handoff sealed → fetch via `xmrhost-cli order handoff --order=xmrhost-2026-05-06-01a3`

$ xmrhost-cli order handoff --order=xmrhost-2026-05-06-01a3
[ok] node-id        = tor-2-is-47
[ok] onion-auth-key = (sealed; written to ./tor-2-is-47.auth_private)
[ok] sshd-config    = (sealed; written to ./tor-2-is-47.sshd_config)
[ok] viewkey        = (skipped; opt-in via --audit-view-key at order time)
[ok] refund-window  = open until 2026-05-13 (7 days)

// the cli is a planned MVP addition; the console UI at /console ships first. The vocabulary above (order / pay status / handoff / refund) is the surface contract — consider it the spec.

// SEE ALSO