// vps, dedicated, gpu, plus tor / i2p / lokinet — provisioning catalog
$ ls -la /
// pick a tree to descend into. each row is a real path on this site.
// the manual — provision a hidden service, harden sshd, ksp kernel checklist
// post-incident write-ups, threat-model essays, RFC-cited deep dives
// the brand stance: BTC for offshore privacy infra is a threat-model bug
$ xmrhost-cli list --short
// a representative slice — full catalog at /node
17 total entries across 6 categories. no-kyc crypto billing (xmr / btc / lightning / ltc / eth / usdt) — see /payments.
$ grep -ri 'why monero is recommended' /etc/xmrhost
// /etc/xmrhost/policy.d/payments.md
You are buying offshore-jurisdiction hosting because the threat model includes subpoena, civil-discovery process, and chain-analytics correlation. Paying with BTC / LTC / ETH / USDT leaves the third surface exposed; paying with XMR closes it at the protocol layer.
The chain-analytics literature is not subtle: Möser-Soska-Christin (FC 2018) on Monero traceability, Meiklejohn et al. (IMC 2013) on BTC clustering, and the EFF/Coin Center filings around the 2024 OFAC Tornado Cash designation are the reading list. /why-monero walks the operator-side mechanics in full and explains why the brand recommends XMR while accepting every standard crypto rail. /payments is the one-pager covering the actual checkout.
# tldr
xmr = recommended (no chain-analytics surface)
btc, ltn, ltc = supported (chain-analytics surface; pay from a clean wallet)
eth, usdt = supported (transparent ledger; convenient for stablecoin holders)
card2crypto = not offered (KYC-equivalent on the funding side)
cash-by-mail = case-by-case, contact /contact $ ls /usr/share/doc/xmrhost
// curated index of the strategic surfaces. not a sitemap; /sitemap.xml is.
// guide/
// pillars
// vs/