The payment rail by which a customer pays for offshore hosting is part of the threat model the hosting was chosen to address. A customer who has moved their published work onto a Reykjavík-hosted virtual server, set up PGP for source correspondence, and configured their Tor entry node — and then paid the invoice with a personal-name Visa — has shifted half the surface and left the other half intact. The card processor’s logs preserve the link between the operating identity and the publishing identity that the hosting jurisdiction was selected to disrupt; the migration is, in practical terms, half-completed.
This article reads the four payment rails OffshorePress accepts — Monero, Lightning, on-chain Bitcoin, and cash by post — against the threat models the customers most likely to use offshore hosting carry. It is a working reference for the choice, not a recommendation. The recommendation, where it belongs, is at the bottom: mix rails rather than commit to one, and treat the choice as part of the publishing infrastructure rather than as a billing detail.
The four rails, in two sentences each
Monero is a privacy-by-default cryptocurrency: every transaction’s sender, recipient, and amount are obscured by construction, through a combination of ring signatures, stealth addresses, and RingCT confidential-transaction commitments. Confirmation lands in approximately twenty minutes for a single confirmation; the operator considers two confirmations sufficient for an invoice paid before service begins.
Lightning is a payment-channel network operated on top of Bitcoin. Payments route through onion-routed Hashed Time-Locked Contracts (HTLCs), which means the intermediate nodes do not see who paid whom; the channel-opening and channel-closing on-chain transactions are visible, but the inflight payments inside the channel are not. Confirmation is effectively instantaneous.
On-chain Bitcoin is the public-ledger transaction layer most readers will be familiar with. Every transaction is recorded permanently, every address’s full history is visible, and chain-analysis firms have built substantial infrastructure to cluster addresses into operator-identity equivalence classes. Confirmation lands in approximately ten minutes per block; six confirmations is the conventional finality threshold.
Cash by post is exactly what it sounds like: an envelope of currency dispatched by registered post to the mail-in address the operator issues post-checkout. Confirmation arrives when the envelope arrives, which is typically three to seven business days from posting in Western Europe and longer from further away. The operational guide for cash-mail-in payments covers the envelope-handling discipline in detail.
What “private” means in each rail
The four rails do not protect the same things. Reading them carefully matters because the customer’s threat model and the rail’s protection model have to overlap; a rail that is private along one axis but public along another is a poor fit for an adversary who attacks the public axis.
Monero is private by construction. The transaction graph is opaque to outside observers: an analyst with the Monero blockchain in front of them cannot determine which address sent funds to which, cannot determine the amount sent, and cannot — without a side channel — link a Monero address to an off-chain identity. The privacy is not at the application layer (a privacy wrapper around a public ledger) but at the protocol layer (the ledger itself does not record the data the analyst would want). For a customer whose threat model includes a chain-analysis adversary, Monero is the rail whose privacy properties match the threat.
Lightning is private along the inflight-payment axis but not along the channel-graph axis. An onion-routed Lightning payment leaves no on-chain trace of who paid whom; the intermediate hops in the route see only the previous and next hop, not the route’s endpoints. The channel-opening and channel-closing transactions are, however, on the public Bitcoin chain, and the topology of which nodes are connected to which other nodes is partially observable through the gossip protocol. For a customer paying a hosting invoice, the Lightning payment itself is private; the channel infrastructure that enables it is partially-public.
On-chain Bitcoin is, on its own, not private. Every transaction is permanently recorded. Every address’s full history is visible to anyone who fetches a block. Chain-analysis firms — Chainalysis, Elliptic, TRM Labs and others — operate at scale on the assumption that addresses can be clustered into operator-identity equivalence classes through heuristics applied to spending patterns, and they sell that clustering to law enforcement, exchanges, and other counterparties. A Bitcoin payment for hosting can be made private through application-layer techniques (CoinJoin protocols like JoinMarket, atomic swaps that exit through Monero, multi-hop privacy-aware wallets like Wasabi or Samourai), but the protection is opt-in, costly, and imperfect.
Cash by post is private at the protocol layer (no ledger to analyse) but produces metadata at the postal layer (the envelope passes through postal sorting infrastructure, and the originating post office’s stamp can sometimes be read from the envelope at delivery). The cash itself is fungible by construction, and once it is in the operator’s till the originating identity is unrecoverable from the cash itself; the surface is the envelope and the act of posting, not the cash inside.
The acquisition surface
The privacy of a payment is upper-bounded by the privacy of the acquisition. A Monero payment routed through a freshly-bought Monero wallet that was funded by a personal-name credit card via a KYC-compliant exchange is a Monero payment whose privacy properties are bounded by the KYC step. The chain-of-custody analyst does not have to break Monero’s protocol to associate the wallet with the operating identity — they can simply read the exchange’s KYC record.
This is the most common failure mode of payment-rail selection in practice. Customers select Monero or Bitcoin for the rail’s protocol-layer privacy properties and then acquire the coin through a fully-KYC’d exchange, producing a payment that is private in transit but contaminated at acquisition. The protocol’s privacy holds only for the link between the wallet and the destination; it does not retroactively erase the link between the funding source and the wallet.
The cleaner acquisition routes are peer-to-peer (Bisq, AgoraDesk, Hodl Hodl, RoboSats) and atomic-swap (Side Shift, FixedFloat, Trocador). Bisq is a desktop-application peer-to-peer exchange that uses a built-in Tor transport and an arbitration model rather than a custodial one — buyers and sellers transact directly, the platform mediates disputes through a deposit system, and no central party holds the coins or the identity records. AgoraDesk and Hodl Hodl are web-platform escrow exchanges that operate without KYC for cash-meet trades and small-volume trades. RoboSats is a Tor-native Lightning peer-to-peer exchange with no registration. Atomic-swap services do not custody the funds and do not perform KYC for typical-volume swaps; their threat model is that the user is converting between cryptocurrencies, not entering or exiting fiat.
For customers who acquired Bitcoin years ago through what was at the time a less-KYC environment, an atomic-swap exit through Monero is a defensible cleanup. For customers entering the cryptocurrency surface for the first time specifically to pay for hosting, the cleanest path is cash-meet through Bisq or AgoraDesk, or — and this is the route the operator most often recommends to customers without prior cryptocurrency experience — cash by envelope, which removes the cryptocurrency acquisition step entirely.
Confirmation cadence and operational tempo
Different rails have different operational tempos, and the tempo matters when migration timelines or service-renewal cadences are involved.
Monero confirms in approximately twenty minutes for one confirmation, forty minutes for two. The operator considers two confirmations sufficient for service to begin against a paid invoice; for renewal cycles where the service is already provisioned and the payment is funding the next cycle, one confirmation is operationally adequate. Lightning is effectively instantaneous: a payment lands and confirms in seconds, bounded by the route’s longest hop. On-chain Bitcoin confirms in approximately ten minutes per block; the operator’s standard threshold is two confirmations for a small invoice and six for a larger one — small here meaning under a few hundred US dollars, large meaning a multi-month annual prepayment. Cash by post is on a postal cadence: three to seven business days within Western Europe, longer from further away, with the envelope confirmation event being the operator’s hand on the envelope rather than a network observation.
For customers timing a hosting cutover — the discipline of which is treated separately in the migration runbook — the cadence question affects scheduling. A migration whose hosting payment is by Monero can settle on a single business day; a migration whose payment is by cash needs the envelope dispatched a week before the cutover with confirmation tracked en route.
When each rail is the right answer
The Monero rail is the right answer for customers whose threat model includes a chain-analysis adversary and whose operational discipline is sufficient to run a Monero wallet — which is, in practice, the majority of customers paying for offshore hosting from a privacy-press posture. The protocol’s privacy properties match the threat model directly, the confirmation cadence is operationally workable, and the wallet ecosystem (Cake Wallet, Feather Wallet, the official monero-wallet-cli) is mature.
The Lightning rail is the right answer for renewal cycles where the customer already has Lightning capacity (a node, a wallet with active channels) and wants the operational convenience of an instant settlement. It is a less defensible choice for first-time payments to a hosting service the customer has not previously transacted with, because the channel-opening transaction itself is a discoverable on-chain event that points the chain-analysis observer at the customer’s Lightning operating identity.
The on-chain Bitcoin rail is the right answer for customers who already hold Bitcoin from a non-KYC acquisition history (a long-time holder, a miner, a peer-to-peer trader) and who do not want to swap to Monero before paying. It is the wrong rail for customers acquiring cryptocurrency specifically to pay for hosting, because the KYC entry point contaminates the rail’s protocol-layer protections.
The cash-by-post rail is the right answer for customers who do not run a cryptocurrency wallet, who are uncomfortable with the operational discipline a wallet requires, or whose threat model places weight on having a financial transaction that does not exist on any digital ledger anywhere. It is also the right answer for the customer who has done all the cryptocurrency acquisition work above and concluded that the operational complexity is not worth the protection — cash is the rail that has the longest history of being the rail that resists state-level financial-surveillance infrastructure, and the historical record is not dismissible.
When to mix rails rather than commit to one
The customers whose payment posture is most defensible mix rails rather than commit to one. A typical mixed posture looks like this: the initial payment for the first month is by cash, posted before the cutover and confirmed at receipt; subsequent monthly invoices are by Monero from a wallet funded through a peer-to-peer exchange; an annual prepayment, when the customer commits to it, is by an atomic-swap exit from a non-KYC Bitcoin position. Each rail’s failure mode is contained: a hypothetical compromise of the Monero wallet does not touch the cash-paid initial period; a hypothetical postal-side metadata leak on the cash envelope does not touch the cryptocurrency-paid renewals.
The mixed posture is also the posture that holds up under the slow grind of operational time. A customer who selects one rail and pays through it for three years has produced a documentary record of their payment cadence on that one rail; the record is itself a forensic surface, even when each individual transaction is private. A customer who rotates rails — cash, then Monero, then back to cash, then Lightning for a renewal — produces a record that does not cluster cleanly into a single operator-identity equivalence class.
For the editorial-register customer (a journalist, an activist, a researcher, a small NGO IT lead), the mixed posture is overhead the customer often does not have time for. The single-rail Monero posture is the working second-best, with the acquisition route being the place where the discipline matters most. Cash by post is the working third-best, well-suited to the customer who has decided the cryptocurrency learning curve is not the highest-value use of their operational attention.
A practical recommendation
For a customer setting up offshore hosting for the first time, with no prior cryptocurrency operational experience and no immediate operational pressure, the operator’s working recommendation is: start with cash by post for the initial month while the migration is settling, learn Monero in the meantime through the documentation at /payments/monero, and switch to Monero from month two onward. The cash payment confirms the financial-surface migration is complete; the Monero learning curve happens without the time pressure of a service that needs to be paid by Friday; and the working steady state is a rail whose privacy properties match the threat model directly.
For a customer with prior cryptocurrency operational experience and a non-KYC Bitcoin holding, the recommendation is to swap a portion to Monero for monthly invoices and keep the Bitcoin holding for annual prepayments where the larger swap fee is amortised over twelve months. For an organisational customer paying invoices on behalf of multiple member outlets, the recommendation is more complex and deserves a separate conversation; the operator’s editorial address is the right place to start that conversation.
The four rails are operationally compatible. The choice between them is part of the publishing infrastructure, not part of the billing detail. Treating it that way is most of the work.