[$ ] Monero is the recommended billing rail — and the rationale

// THE SETTLEMENT-RAIL LEAK

$ grep -ri 'leak' /etc/xmrhost/policy.d/payments

Offshore hosting moves the operator's surface out of one jurisdiction's reach. That defeats subpoenas to the local incumbent, civil-discovery process from a domestic plaintiff, and the kind of ex-parte preservation order that lands at 4 p.m. on a Friday. It does not, on its own, defeat chain-analytics correlation. The chain-analytics adversary works downstream of the host: it watches the settlement rail you used to pay for the box, walks the cluster backwards through KYC on-ramps, and reaches a name on a passport that was scanned at a fiat exchange six months ago.

Pay in BTC and the cleartext receipt survives the host's jurisdictional immunity. Pay in XMR and there is no receipt to seize. That is the argument for Monero — everything below is annotation. The operator offers BTC, Lightning, USDT, and ETH alongside XMR because not every customer threat model weights chain-analytics privacy the same way; a customer with a low-stakes threat model (basic offshore convenience, no adversarial intelligence operation) can use any rail and the practical outcome is identical. Customers with stricter threat models should default to XMR.

// STATE OF THE ART — BITCOIN CHAIN ANALYTICS

$ man chainalysis

The academic record on Bitcoin de-anonymisation is unambiguous, dates back more than a decade, and has been operationalised at industrial scale by commercial vendors.

• Meiklejohn et al., "A Fistful of Bitcoins" (IMC 2013). Demonstrated multi-input clustering and change-address heuristics that collapse most active BTC wallets into a single cluster within weeks of activity. The protocol has not changed since; the heuristics still apply.
• Ron and Shamir, "Quantitative Analysis of the Full Bitcoin Transaction Graph" (FC 2013). Earlier large-scale graph analysis on the entire chain at the time, mapping the long-tail distribution of address activity.
• Möser et al., "An Inquiry into Money Laundering Tools in the Bitcoin Ecosystem" (eCrime 2013). Early evaluation of mixers as a mitigation; the conclusion held up: most mixers are themselves chain-analytics targets, not solutions.
• Commercial tooling. Chainalysis Reactor, TRM Labs, Elliptic Investigator, and CipherTrace operate on these primitives at industrial scale. They tag exchange addresses, ransomware wallets, mixing services, sanctioned addresses, and increasingly the ordinary self-custody clusters of consumers who paid for SaaS in BTC.

Lightning is not an answer. Channel open and channel close transactions land on the base chain and inherit every cluster heuristic that applies there; intermediate hops that transit through a hostile routing node leak amount and timing; and the receiver's invoice identifier (the lnbc... string) is one round-trip away from a destination wallet that almost certainly funded itself out of a clusterable on-chain UTXO.

// WHAT MONERO ACTUALLY DOES

$ cat /etc/monero/protocol.txt

Monero deploys three protocol-level privacy primitives that compose to sever the address-graph that BTC analytics depends on. Reading the Monero Research Lab papers in the order they were published is the fastest way to understand what is and is not in scope.

• Stealth addresses (CryptoNote, MRL-0001). The public address you publish is not the address that receives any given transaction. Each payment derives a one-time output address from the recipient's view-key pair. The chain shows that address received funds; it does not show which long-lived account the address resolves to without the view key.
• Ring signatures (CryptoNote → RingCT). Every input is signed against a ring of decoys drawn from prior outputs of the same denomination. An external observer cannot tell which member of the ring is the actual spend. Since the 2019 hard fork the ring size has been a fixed 16 members, removing the variable-ring fingerprint earlier analyses (Möser-Soska-Christin, FC 2018) used.
• RingCT + Bulletproofs (MRL-0005, MRL-0011). Transaction amounts are encrypted on-chain via Pedersen commitments and proven correct via Bulletproofs zero-knowledge range proofs. The chain shows that some amount was transferred; it does not show how much. This breaks the amount-correlation heuristics that BTC analytics relies on for cluster confirmation.

Möser, Soska, Christin, and others' "An Empirical Analysis of Traceability in the Monero Blockchain" (FC 2018) is the most-cited paper on Monero traceability. It documented several pre-RingCT decoy- selection weaknesses on transactions from 2014–2016. Those heuristics do not apply to post-2017 transactions: every transaction is RingCT from a fixed-16 ring, and the decoy-selection algorithm has been reworked twice since the paper. The honest summary is "Monero raises the cost of de-anonymisation by orders of magnitude, the residual attacks are tractable to the operator who knows them, and the post-2020 chain has not been productively analysed at industrial scale". For privacy-infra hosting that gap is enough.

// THE LEGAL TEMPERATURE — OFAC, FinCEN, EU MiCA

$ tail -f /var/log/financial-surveillance.log

Designating privacy-preserving software as financial-surveillance avoidance is not theoretical. The August 2022 OFAC designation of the Tornado Cash smart contract addresses, and the follow-on actions through 2023–2024, made the point explicitly: writing code that breaks chain-analytics primitives is treated by the executive branch as a sanctionable activity rather than as protected speech. Coin Center's amicus brief in Van Loon v. U.S. Department of the Treasury and the EFF's filings on the same docket are the primary reading.

That posture is not Monero-specific, but it raises the cost of treating "we accept BTC and we tumble through a mixer" as a privacy story. Tornado Cash users discovered that mixer designation retroactively contaminates their on-chain history; Wasabi and Samourai users learned the same lesson on the BTC side. Monero's privacy is on-protocol, not on-mixer; there is no smart-contract front to designate. The EU Markets in Crypto-Assets regulation (MiCA), in force since June 2024, has triggered most regulated European exchanges to delist privacy coins entirely, which makes the on-ramp narrower but does not change the on-chain story.

// THE OPERATOR-SIDE COMMITMENT

$ man xmrhost-billing

On the operator side, the full mechanics live at /payments. Summary across every supported rail:

• OxaPay no-KYC processor. Invoices route through OxaPay's hosted checkout (no Card2Crypto bridge, no card surface, no KYC handoff). Operator receives crypto into the merchant wallet; the processor is the only intermediary.
• Per-order Monero subaddresses when paying in XMR. Each invoice mints a fresh subaddress derived from the operator's view-key pair (MRL-0006, Sarang Noether). No address reuse across orders on the chain.
• Customer-paid network fees on volatile rails. BTC / LTC / ETH / Lightning customers pay their own network fees; OxaPay handles fee estimation and shows the all-in total before the customer confirms.
• Refund mechanics. Refunds are returned in the same currency as the original payment, to a customer-supplied address. No fiat off-ramp on either side; no exchange KYC introduced by the refund flow.

// WHAT WE DO NOT ACCEPT, AND WHY

$ grep -v xmr /etc/xmrhost/payment-rails

// HOW TO ACQUIRE XMR WITHOUT BREAKING THE THREAT MODEL

$ 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 identity to the hosting purchase. That property is undermined if the XMR is acquired through a service that requires government ID, address verification, or a bank account in the customer's name. Acceptable on-ramps are restricted to 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, Haveno (and Haveno forks such as RetoSwap) — federated peer-to-peer trading; XMR collateral on the Haveno side. Tor-routed by default.
• Atomic-swap brokers. SideShift, FixedFloat, Trocador (a meta-aggregator), Majestic Bank, eXch — crypto-in / crypto-out, no account, fixed-rate or variable-rate.
• Wallets. Feather (desktop, BSD), Cake Wallet (mobile, BSD), Monerujo (Android, GPLv3), monero-gui / monero-wallet-cli (official). All open-source, all support remote nodes over Tor. Power users run a local node.

// Unacceptable on-ramps for this threat model: any centralised exchange that gates Monero behind ID verification. Routing through one of those defeats the point. 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.

// FREQUENTLY-ASKED OBJECTIONS

$ faq -p why-monero

// SEE ALSO

$ ls /usr/share/doc/xmrhost/payments

• /payments — the operator-side billing mechanics: subaddress derivation, view-key transparency, refund flow, cycle discounts.
• /notes/monero-subaddresses-for-hosting — long-form on the subaddress workflow specifically, including MRL-0006 and the Cake / Feather wallet sweep behaviour.
• /docs/monero-subaddress-workflow — runbook for customers who want to operate per-order subaddresses on their own side.
• /legal/refund — the legal text behind the refund flow (returned in the same currency as payment to a customer-supplied address).
• /contact — for cash-by-mail or unusual arrangements outside the standard rail.

// the position summarised here is the operator's, not legal or financial advice. The reading list (Meiklejohn 2013, Möser-Soska-Christin 2018, MRL-0001/0005/0006/0011, Coin Center and EFF Tornado Cash filings) is the primary source — read it.