The cash-mail-in payment route is the lowest-metadata payment option OffshorePress offers. It is also the operationally most demanding for both the customer and the operator, and the route that benefits most from a published guide setting out the protocol in plain prose. This article is that guide. It is written from the operator’s side of the protocol and is intended to be read in full before a customer chooses to pay this way; the operator’s view is that an underprepared cash-mail-in attempt is materially worse for the customer’s posture than an over-rehearsed Monero payment, and the article is structured to help a reader make that judgement before the envelope is sealed.
Why the operator offers the route
The four payment routes OffshorePress accepts — Monero, Bitcoin over the Lightning Network, on-chain Bitcoin, and cash by post — were chosen because each carries a different metadata profile and because the right choice for a given customer depends on the threat model the customer is working to. Monero is the default; for most customers, paying in Monero from a self-custodial wallet is the right balance of operational ease and metadata minimisation. The cash-mail-in route exists for the cases that Monero does not serve.
The structural cases the operator has documented include the customer who is operating in an adversarial state where Monero acquisition is not realistic — either because the cryptocurrency exchanges accessible to the customer are KYC-bound and the customer cannot afford the chain that creates, or because the customer’s threat model includes adversaries with sophisticated chain-analysis capabilities and the customer judges that the on-ramp risk outweighs the privacy gain Monero offers downstream. The cash-mail-in route exists for the customer who can acquire physical banknotes without a metadata trail and who would rather pay through the postal system than through any digital intermediary at all.
A second case is the customer for whom the operator’s published cryptocurrency rails are not yet practically usable. Some adversarial jurisdictions block the major cryptocurrency exchanges entirely; some customers are operating from networks where the kind of traffic Monero or Bitcoin transactions generate is conspicuous. The operator’s view is that the existence of a non-cryptocurrency payment route is part of what makes the catalogue serve the audience for which it was designed; a payment offering that requires every customer to be already-comfortable with self-custodial cryptocurrency is a payment offering that excludes a substantive part of the audience.
The hold-mail address
The single most common operational question the operator receives about this route is the address. The address is not published on the public website. It is issued, per-customer, in a PGP-encrypted message sent to the customer’s nominated key after the customer has selected the cash-mail-in route during checkout. The operator considers the per-customer address pattern essential to the route’s privacy properties and considers a single published hold-mail address operationally inferior — a published address creates an aggregation point that an adversary could surveil at the postal-system level, and the per-customer pattern decouples the routing.
The customer’s nominated PGP key is collected during the checkout flow and verified against a key-server lookup before the address is issued. A customer without an existing PGP key can generate one for the purpose; the operator’s checkout flow includes a sober walkthrough of the gnupg command sequence for a customer who has not previously held a key. The address is rotated on a documented schedule for the operator’s own operational reasons and the customer is notified of any rotation by encrypted message before it takes effect.
The address routes to a mail-handling counterparty under contract with the operator. The counterparty is a Swiss-licensed mail-forwarding firm with a documented privacy-by-design posture; the operator does not name the counterparty in this article because naming it in a public document would create exactly the surveillance aggregation point that the per-customer address pattern is designed to avoid. The contract between the operator and the counterparty includes specific provisions on opening, scanning, and disposing of envelopes; the operator is happy to share the contract on request to a customer who wants to verify the arrangement before paying.
What the envelope should contain
The envelope should contain the banknotes and a single piece of paper bearing the customer’s account identifier and nothing else. The account identifier is a base32 string the customer is given on the order-confirmation page; it is not the customer’s pseudonym, not the customer’s email address, not the customer’s PGP fingerprint, not any string the operator could correlate to any other identifier the customer holds. The identifier exists for the sole purpose of letting the operator’s receiving counterparty match the cash receipt to the customer’s open invoice.
The denominations the operator accepts are CHF 50, CHF 100, CHF 200; EUR 50, EUR 100, EUR 200; GBP 20, GBP 50; USD 20, USD 50, USD 100. The operator does not accept envelopes containing larger-denomination Swiss banknotes (the CHF 1000), Euro banknotes denominations the European Central Bank has phased out (the EUR 500), or any banknote whose serial number has been recorded by an enforcement agency in connection with a documented criminal investigation. The operator’s receiving counterparty performs the standard counterfeit-detection checks on receipt; envelopes containing detected counterfeits are returned to the postmark address with the operator’s regret and the customer’s account is not credited.
The envelope should not contain any item other than the banknotes and the account-identifier slip. A customer who places a personal note, a return-address sticker, a cover letter, or any other item in the envelope is creating metadata that the operator’s documented privacy posture requires the operator to dispose of unread, but the existence of the additional metadata at the postal-system level is outside the operator’s control. The envelope should not contain coins; coin handling is operationally expensive and the operator’s receiving counterparty is not equipped for it. The envelope should not contain any item that would identify the sender to the operator; the operator’s view is that an envelope identifying its sender is a payment route that fails the route’s own privacy purpose.
What the envelope should look like
The operator’s recommendation, drawing on the documented practice of the European mail-handling community that has used hold-mail addresses for legitimate operational purposes for decades, is that the envelope be a standard plain manilla mailer of the size that fits a folded A4 sheet. The envelope should be stamped or franked at the customer’s local post office; the operator does not recommend the use of a courier service for cash payments because most courier services maintain detailed manifests that materially raise the metadata floor of the transaction. The envelope should not bear a return address; postal regulations in most jurisdictions do not require one for ordinary letter post within continental Europe.
The envelope should be sent by ordinary mail, not registered mail. Registered mail introduces a tracking record that the operator’s privacy posture would prefer to avoid and that the customer’s privacy posture should also prefer to avoid. The trade-off is that ordinary mail does not give the customer a receipt of posting; the operator’s response to that trade-off is the receipt protocol set out in the next section, which is intended to give the customer functional confirmation of receipt without the metadata cost of a tracked-mail record.
The customer should send the envelope from a post-office or street-letter box that is not the customer’s nearest. The operator does not require this; the operator notes it because the customer’s posture is improved by the practice and because the cost of the practice is low. A customer whose threat model includes a state-level adversary capable of correlating postal-deposit-point records to a customer identity has an entire literature on the subject of mail-deposit operational security to draw on; the operator’s article cannot improve on that literature and points the reader at it.
The receipt protocol
On receipt of the envelope at the operator’s mail-handling counterparty, the counterparty opens the envelope, performs the counterfeit-detection check, counts the contents, records the account identifier from the slip, destroys the slip, and forwards the count and the identifier to the operator over an encrypted channel. The operator credits the customer’s account in the published bookkeeping ledger and issues a receipt to the customer’s contact address — the address the customer provided at signup. The receipt is sent within one business day of the operator’s receipt of the counterparty’s notification, which in normal circumstances is within one business day of the envelope arriving at the mail-handling address.
The receipt is a sober record of the credit applied to the account. It does not include any reference to the postmark, the return address (if any), or the contents of the envelope beyond the count of denominations. A customer who wants a more detailed receipt for the customer’s own bookkeeping can request one and the operator will provide it; the default is the lean receipt because the lean receipt creates fewer durable records that an adversary could later compel disclosure of.
If the customer has not received the receipt within ten business days of the customer’s recorded posting date, the customer should write to the operator’s editorial address from the contact address on file. The operator will check the receiving counterparty’s records for the account-identifier string and respond with the disposition. The most common cause of a missing receipt, in the operator’s experience, is that the envelope was lost in the postal system between the customer’s deposit point and the receiving address; the second most common cause is that the customer has mistyped the account identifier on the slip, in which case the cash is held in the operator’s unattributed-receipts pool until the operator can match it. The operator’s policy is to make a good-faith effort to match unattributed receipts for ninety days, after which the cash is donated to a Swiss-registered press-freedom charity and the donation is documented in the operator’s annual transparency note.
Disputes and refunds
A customer whose payment-by-post does not result in a service the customer considers satisfactory has the same dispute mechanism as a customer who paid in any other route — a written report to the operator’s operations address, an investigation by the operator’s operations team, and a documented response. The operator’s refund policy applies; refunds are paid in the same route as the original payment, which means a cash-mail-in customer’s refund is mailed back as cash to an address the customer provides at the time of the refund request. The address can be different from the address the original payment was mailed from; the operator does not retain the postmark of the original payment and so could not return to the original address even if the customer wished.
The operator’s view is that the refund route is one of the protocol’s structural strengths. A customer paying through a card processor whose chargeback rights have been historically applied against the categories of customer the operator serves does not actually have a refund right, only a discretion that the processor may or may not exercise. A customer paying in cash by post, with a written refund-on-request policy and a published track record of honouring refunds, has a stronger contractual position than the card-paying customer in the same situation, even though the operational mechanism looks more cumbersome on its face. The legibility of the protocol is part of what makes the protocol’s privacy properties hold up.
When not to use this route
The cash-mail-in route is not the right route for every customer. A customer whose Monero infrastructure is already in place, who is comfortable transacting from a self-custodial wallet, and whose threat model does not include adversaries who would be triggered by the metadata floor of a Monero transaction is better served by the Monero route. The cash route’s added complexity — the PGP-encrypted address exchange, the postal-system dependency, the up-to-ten-business-day settlement window — is not justified for a customer whose default rail is operationally easier and metadata-comparable.
A customer whose subscription is at the upper end of the operator’s catalogue — a multi-machine dedicated configuration, a high-usage email account at the unlimited tier — is operationally better served by the cryptocurrency rails. The cash route is bounded by the practical maximum that fits in a standard envelope — at the largest Swiss-franc denomination the operator accepts, that is around CHF 4000 per envelope — and a customer whose subscription exceeds that bound either has to send multiple envelopes (which raises the metadata floor of the relationship in ways the cryptocurrency rails do not) or to use a different rail. The operator’s catalogue includes DS-PRO and DS-BEAST tiers whose monthly fees place them in this position; the operator’s recommendation for these tiers is Monero by default.
A customer whose threat model includes a postal-system adversary is not well served by this route at all. The article cannot improve on the operational-security literature that customer should consult; the operator’s view is that an honest acknowledgement of the route’s failure-mode is more useful to the customer than the pretence that the route is universally suitable. The catalogue’s other payment routes exist for the customer for whom this route is the wrong choice; the per-route dossier under /payments sets out the comparable considerations for the cryptocurrency rails.
A closing note on the operator’s posture
The operator considers the publication of this guide part of the service. A customer who pays in cash by post on the strength of this article and the per-route dossier under /payments is a customer the operator considers operationally well-prepared; a customer who pays without consulting either is a customer the operator would prefer had read further first. The article is long because the protocol is non-trivial and because the audience for which the operator was set up reads carefully. The operator’s view is that an honest payment route is a payment route the customer can read end-to-end before taking the first action — and that the payment route’s own documentation is therefore part of the route’s operational privacy posture, not an afterthought to it.