Bitcoin

Why this rail

On-chain Bitcoin is the cryptocurrency every wallet supports, the rail every counterparty understands, and the settlement layer with the longest history of resisting protocol-level capture. It is also fully transparent. Every transaction sits on a public ledger that chainalysis firms have spent a decade learning to cluster, and the heuristics they apply are competent. A customer paying for OffshorePress from a wallet whose history contains a KYC exchange withdrawal has not been anonymous for some time before the payment was constructed.

We accept on-chain BTC through a self-hosted BTCPay Server. No third-party processor sits between the wallet and the operator, no payment intermediary can refuse a transaction or freeze a receipt, and every invoice is issued against a fresh receiving address that is not reused for a subsequent order. The payment infrastructure is operated under the same legal cover as the hosting layer; nothing about a Bitcoin payment routes through a third party that OffshorePress does not control.

For customers who want to pay on-chain and care about the transactional privacy of the payment, the discipline lives on the wallet side rather than on the operator side. Coin-management wallets that perform CoinJoin internally (Wasabi, Samourai's successors) provide unlinkability between previous wallet history and the outgoing payment. Atomic-swap acquisition (Side Shift, FixedFloat, Trocador for cross-chain conversion from XMR to BTC immediately ahead of the send) breaks the history altogether. P2P acquisition through Bisq, Hodl Hodl, AgoraDesk, or RoboSats keeps the on-ramp itself off the KYC ledger.

Confirmations are taken at one for invoices under five hundred dollars (typically thirty to sixty minutes), three confirmations between five hundred and five thousand, and six above. The thresholds are network-conservative against block-reorganisation risk and are not tightened on customer request — the order page polls the mempool and updates status as confirmations land.

How to pay

At checkout, choose Bitcoin as the payment rail. The order page generates a fresh receiving address scoped to this invoice and an exact BTC amount, denominated from a coingecko mid-price. The address is never reused for a subsequent order. A QR encoding both the address and the amount is rendered alongside the plain string for wallets that prefer it.

From a self-custodial wallet — Sparrow on desktop, Electrum running over Tor, a hardware-wallet pairing through Ledger or Trezor, or one of the CoinJoin-aware wallets if previous-history unlinkability matters — send the indicated amount at an economy fee tier or higher. The economy tier confirms in roughly one to two blocks under typical mempool conditions; high-priority fees buy a slot in the next block at the cost of a few extra dollars per send.

The invoice page polls the chain and updates as confirmations land. Provisioning fires once the threshold for the invoice tier is met. A short underpayment (under one percent of the invoice) is auto-credited; a larger underpayment holds the invoice open until topped up. A send to a stale address from an expired invoice is recoverable by writing in with the transaction id, which the operator can match against the internal ledger.

Closing notes

On-chain Bitcoin is the rail to pick when the invoice amount argues against Lightning, when the sending wallet does not yet support Lightning, or when the paying counterparty already settles in on-chain BTC for everything else. It is the wrong rail to pick when financial surveillance is part of the threat model — pick Monero in that case, or apply the on-wallet discipline (atomic swap, coin management, P2P acquisition) the rail demands of a privacy-conscious sender.