Most "privacy hosting" in our market is no-KYC signup paired with clearnet control panels that fingerprint your browser, accept your clearnet email at signup, store your billing identity in the same database as every other customer, log your IP address at every request, and retain those logs for years. The phrase "no KYC" has been diluted into the privacy version of the phrase "natural ingredients" on a packet of crisps. Privacy Stack Pack treats privacy as an engineering problem and documents the technical choices rather than the marketing claims.
Eight components engineered together. Tor hidden service (.onion v3 address) exposing the customer control panel and an authenticated SMTP submission endpoint, so customers running operations from inside Tor never have to traverse public Tor exit nodes (which are recorded as malicious by every email reputation service). Monero billing handled on an isolated accounting system separate from our clearnet customer database. Email-only signup with zero identity documents requested. Logs retained 7 days then cryptographically purged through daily-rotated encryption keys. Clearnet/onion network isolation at the host level with separate IP space and routing. PGP-encrypted support channel with keys rotated quarterly. Annual operational privacy audit by an independent third party with sanitised report available to all customers. EUR 1,499 setup, EUR 299 monthly. We do not promise absolute anonymity; we promise documented operational practices that hold up under audit.
The biggest mistake in privacy infrastructure is buying defences that do not match your threat model. Select your scenario and we will tell you which components of Privacy Stack Pack are sufficient, which require additional layers, and which require a different category of defence entirely. We are explicit about scope rather than selling the same package to every scenario.
Privacy Stack Pack engineers the infrastructure layer honestly. None of it matters if the customer leaks their identity through operational mistakes. Run the checklist below; a single confirmed mistake is enough to defeat the rest of the stack. We publish this checklist because the most common failure mode in privacy operations is overconfidence in tools that the customer's own behaviour has already undermined.
Check any mistake you have made or might make. Each confirmed mistake reduces your effective privacy posture regardless of infrastructure choices.
The privacy hosting market in 2026 splits into three tiers with a large gap between two of them. At the bottom: providers using "no KYC" as a marketing phrase while running standard clearnet infrastructure with conventional logging, payment processing through payment partners that know who you are, and customer databases that any subpoena would empty in 48 hours. At the top: customers running Tails or Whonix on air-gapped hardware, buying Monero peer-to-peer, using burner phones, and treating every interaction with hosting infrastructure as adversarial. The gap in the middle is where most operationally serious customers actually live, and the market has not served them well.
Privacy Stack Pack is engineered for the middle. A customer who needs operational privacy as a business requirement (privacy-focused SaaS company, independent journalism platform, activist communications operation, legal whistleblower channel, cryptocurrency-adjacent business avoiding extraneous KYC surface, ordinary businesses tired of every vendor accumulating their identity for resale to data brokers) needs a different deal than the no-KYC marketing tier offers, but is not operating under the threat model that justifies the full Tails-on-hardware approach. The middle deal looks like this: minimal data collection at signup, technical isolation between identity contexts at the infrastructure level, short and cryptographically enforced log retention, payment methods that do not require identity disclosure to function, transparent documentation of what is logged and for how long, and an honest threat model with no marketing claims about absolute anonymity.
The technical choices reflect that middle position. Tor v3 onion services for the control panel because v3 addresses are cryptographically resistant to the enumeration attacks that compromised v2; we publish the .onion address openly because hiding the address would defeat its purpose (Privacy Stack customers are told the address at signup and it appears in our published documentation). Monero as the recommended payment method because it is the only widely-used cryptocurrency with privacy as the default rather than as an optional feature; we accept BTC, LTC, ETH, and USDT but we are explicit that chain analysis can link those payments to your identity through any historical KYC exchange touch. Log retention at 7 days because shorter creates operational problems for legitimate troubleshooting and abuse handling while longer becomes a target for legal process; the 7-day window is short enough to limit exposure and long enough to support operations. Cryptographic purge through daily-rotated encryption keys because soft deletion has a backup recovery path that we explicitly do not want; destruction of the decryption key on day 7 makes the encrypted logs unrecoverable even by us.
The bridge guard relay deserves a specific explanation. A common pattern for privacy-serious customers is running their operations from inside Tor: their endpoint is Tails or Whonix, their entire network stack is Tor-routed, and they do not have a clearnet connection at all. For most service providers this works fine. For email it does not, because Tor exit nodes are recorded as malicious by virtually every email reputation service in the world. If your SMTP submission exits Tor through a public exit node, your mail will be rejected regardless of message content. The bridge guard relay solves this. The customer's Tor client connects to our bridge guard relay (operated by us, not a public node), authenticates with a customer-specific token, and the SMTP submission forwards to our infrastructure over an authenticated channel. The outbound SMTP traffic exits from our own clean IP space rather than a Tor exit node. The customer retains the privacy benefit of their endpoint seeing only Tor traffic; the email retains the reputation benefit of clean IP origin.
The annual operational privacy audit is the accountability layer. Customers cannot verify internally what we actually log, how long we retain it, and whether our purge mechanism functions as documented. An independent third party (rotated every three years to prevent capture) audits the operational practices: reviews our retention policies against actual log storage, tests the cryptographic purge by inspecting unmounted storage for residual data, verifies the clearnet/onion isolation at the routing and storage layer, examines incident response records for compliance with documented procedures. The sanitised audit report is delivered to all Privacy Stack Pack customers within 30 days of audit completion. The full unsanitised report is available to customers conducting their own due diligence under NDA.
56-character .onion v3 address for control panel access and SMTP submission. The v3 protocol uses Ed25519 keys and is cryptographically resistant to the enumeration attacks that compromised v2. Address published openly at signup; the privacy comes from the network layer, not from hiding the address.
XMR billing handled on a separate accounting system from our clearnet customers. No cross-reference between the two databases at application or storage level. Other cryptocurrencies accepted on request with explicit warning about chain analysis risks for transparent coins.
Contact email plus optional PGP public key. No legal name, no postal address, no phone number, no tax ID, no government identity documents. Signup page itself does not log IP address. The data we never collected cannot leak to legal process.
Logs stored encrypted with a daily-rotated key. On the 7th day after creation, the corresponding decryption key is destroyed. Encrypted logs become mathematically unrecoverable even by us. Soft deletion alternatives have backup recovery paths that we explicitly do not want.
Clearnet customers and Privacy Stack customers operate on separate IP space with separate routing policies. Logs for the two segments are stored separately. Internal correlation between segments is prevented at the application boundary. An internal audit cannot trivially link the two identity contexts.
Dedicated guard relay we operate for SMTP submission from Tor. Customer's Tor client authenticates with customer-specific token, traffic forwards to our infrastructure over authenticated channel, SMTP exits from our clean IP space rather than a public Tor exit node. Solves the exit node reputation problem.
Support requests can be sent encrypted with our published PGP key. Keys rotated quarterly with previous-key acceptance window. Decryption happens on an air-gapped support workstation; the cleartext does not enter our support ticketing system. Honest scope: this protects content from us at rest, not from compromise of the support operator's terminal.
Third-party operational audit reviewing retention policies, cryptographic purge mechanism, clearnet/onion isolation, incident response compliance. Auditor rotated every three years to prevent capture. Sanitised report delivered to all Privacy Stack customers within 30 days of completion. Full report under NDA on request.
We accept multiple cryptocurrencies on Privacy Stack Pack but we are explicit about which ones provide actual billing privacy and which ones provide the illusion of privacy. The comparison below covers billing-relevant attributes only; on-chain capability for transfer between wallets is a separate question.
| Coin | Privacy default | Chain analysis resistance | Billing recommendation |
|---|---|---|---|
| Monero (XMR) | Mandatory privacy on every transaction (ring signatures + stealth addresses + RingCT) | High in 2026; largest anonymity set among privacy coins; some early transactions had analytical weaknesses now patched | RECOMMENDED |
| Zcash (ZEC) | Optional shielded transactions; most usage is transparent | Strong for shielded-to-shielded; statistical analysis can sometimes link shielded amounts to transparent flows | ACCEPTED (shielded only) |
| Bitcoin (BTC) | None; all transactions transparent on the public ledger | Low; chain analysis firms maintain databases linking addresses to KYC exchange identity | ACCEPTED (with warning) |
| Litecoin (LTC) | None on main chain; MimbleWimble Extension Blocks optional but rarely used | Low; same chain analysis exposure as Bitcoin | ACCEPTED (with warning) |
| Ethereum (ETH) | None; transparent ledger with extensive analytical tooling | Low; widely instrumented by analytics firms | ACCEPTED (with warning) |
| USDT (Tether) | None; transparent across all chains it operates on | Low; centralised issuer can freeze addresses | ACCEPTED (with warning) |
Why we accept transparent coins despite the privacy limitations: not every customer can acquire Monero easily. Regional availability varies, peer-to-peer markets require effort, and some operations have accounting requirements that favour widely-used coins. We are honest about the trade-off: a Monero payment is substantially more private than a Bitcoin payment for billing identity purposes. Customers choose; we document the implications.
Companies whose product is privacy itself (encrypted messaging, VPN providers, privacy-coin exchanges, secure file sharing) need backend infrastructure consistent with their customer-facing privacy posture. Hosting from a no-KYC marketing provider with conventional logging undermines the product story; Privacy Stack Pack engineering matches.
Independent news operations and investigative journalism platforms targeting publication of material that powerful subjects would prefer suppressed. Privacy Stack Pack reduces the data available about the operation to potential legal process. Honest scope: state-level adversaries need additional layers beyond hosting alone.
Secure channels for whistleblower contact with journalists, lawyers, or oversight organisations. The Tor v3 onion endpoint and minimal data collection model fit the threat profile. The channel operator combines Privacy Stack with SecureDrop or similar specialised tooling.
Cryptocurrency-adjacent operations (non-custodial exchanges, privacy-coin services, decentralised finance interfaces) that operate legally but want to minimise the KYC surface attached to their infrastructure decisions. Privacy Stack Pack avoids adding another data broker entry to the operation.
Civil society organisations operating in jurisdictions where membership or financial support could create personal risk for participants. Privacy Stack Pack reduces the data tying the organisation to its supporters and operators. Pair with operational security training for personnel.
Many ordinary businesses prefer not to feed another vendor database that will eventually be sold to data brokers, breached by attackers, or subpoenaed in unrelated litigation. Privacy Stack Pack is the "minimal vendor data accumulation" option without an exotic threat model.
Eight components engineered together. First: a Tor hidden service (.onion v3 address) exposing the customer control panel and an SMTP submission endpoint for senders who want to push mail from inside Tor. Second: Monero (XMR) billing handled on a separate accounting system from our clearnet customers (no cross-reference between identities). Third: email-only signup, no name, no postal address, no phone number, no identity documents requested at any point. Fourth: log retention capped at 7 days then cryptographically purged. Fifth: clearnet and onion traffic isolation at the host level, separate IP space, separate routing. Sixth: bridge guard relay for SMTP submission from Tor so the customer never has to traverse exit nodes for outbound mail. Seventh: PGP-encrypted support channel with keys rotated quarterly. Eighth: annual operational privacy audit conducted by an independent third party, sanitised report delivered to all Privacy Stack customers. Setup EUR 1,499 once, EUR 299 monthly recurring.
Honest answer: no-KYC is the lowest bar. Most providers advertising no-KYC still log your IP at signup, accept your clearnet email, store your billing identity in their general customer database, and run clearnet-only control panels that fingerprint your browser. Privacy Stack Pack treats privacy as an engineering problem rather than a marketing claim. The control panel runs on a v3 onion address. The billing system runs on a separate database from our clearnet customers, isolated at the application and storage layer. Logs are purged on a 7-day cycle with cryptographic shredding rather than soft deletes. Bridge guard relay means your sending traffic never traverses Tor exit nodes (which are recorded as malicious by most reputation services). The operational privacy audit is conducted by an independent firm whose sanitised report is available to all customers. We are transparent about what we do and do not log; that transparency is itself a differentiator from the no-KYC marketing tier.
Yes, with honest scope. No hosting infrastructure can deliver absolute anonymity; the upstream colocation operator sees physical hardware, the network carriers see traffic patterns, and customer behaviour can leak information regardless of infrastructure design. What hosting can deliver is a documented operational posture: minimal data collection at signup, isolated billing identity, short log retention, technical isolation between clearnet and onion traffic, payment methods that do not require identity disclosure, and clear documentation about what we do log and for how long. The combination significantly reduces the data available about a customer, but it does not eliminate the threat model where a sophisticated adversary correlates traffic across multiple observation points. Customers needing protection against state-level adversaries should additionally use Tor, Tails or Whonix on their endpoint, and treat hosting as one layer of a multi-layer defence rather than the entire defence.
Three threat tiers with honest scope. Tier 1: passive commercial surveillance such as data brokers, ad networks, marketing tracking firms, vendor enrichment services, and general internet metadata aggregation. Privacy Stack Pack protects fully against this tier; we collect almost nothing to leak. Tier 2: targeted investigation by competitors, civil litigants, journalists, or single-jurisdiction subpoena. Privacy Stack Pack provides strong protection through minimal data collection, short log retention, jurisdictional positioning (datacenter in non-EU non-US locations), and crypto billing without identity link. The subpoena cannot extract what we never stored. Tier 3: state-level adversary with full subpoena power, telecom intercept capability, and possible endpoint compromise. Privacy Stack Pack alone is not sufficient against Tier 3; the customer needs additional layers (Tails, Whonix, hardware separation, burner devices, full operational discipline on the endpoint). We are explicit about this scope rather than pretending hosting alone defeats state-level adversaries.
Monero is the only widely-used cryptocurrency with privacy as the default rather than as an optional feature. Bitcoin transactions are permanently public on the blockchain; sophisticated chain analysis can link addresses to identity if any address in the chain touches a KYC exchange. Zcash offers optional shielded transactions but most usage is transparent; statistical analysis can sometimes link shielded amounts to transparent flows. Monero uses ring signatures, stealth addresses, and confidential transactions as the default behaviour for every transaction, with no transparent fallback. The 2026 anonymity set for Monero transactions remains the largest in the privacy coin segment. Bitcoin, Litecoin, ETH, USDT, and other transparent coins are accepted on our clearnet customer billing system but Monero is recommended specifically for Privacy Stack customers who want the strongest practical billing privacy. We accept BTC and others on Privacy Stack with explicit warning that chain analysis can link those payments to identity through historical KYC touches.
Yes, with disclosed scope and retention. We keep operational logs required to run the service: SMTP transaction logs for delivery troubleshooting (7 days, then cryptographically purged), authentication logs for security investigation (7 days), system logs for infrastructure health (7 days), abuse handling records for spam complaint correlation (30 days for the abuse record only, source data purged on day 7). We do not retain content of email messages, do not retain recipient lists, do not retain message bodies, do not correlate sending patterns across customers, do not generate behavioural profiles. Cryptographic purge means logs are stored encrypted with a daily-rotated key; on the 7th day the corresponding decryption key is destroyed making the encrypted logs unrecoverable even by us. We document the retention policy in writing as part of the Privacy Stack Pack onboarding and have it independently audited annually.
For customers running their sending operations from inside Tor (rare but real use case), there is a structural problem: Tor exit nodes are recorded as malicious by virtually all email reputation services. If your SMTP traffic exits Tor through a public exit node, your mail will be rejected or marked as spam regardless of message content. A bridge guard relay solves this. The customer Tor client connects to a dedicated guard relay we operate, the guard relay forwards the SMTP submission to our infrastructure over an authenticated channel, and the SMTP traffic exits our own clean IP space rather than a Tor exit node. The customer retains the privacy benefit of routing through Tor (their endpoint sees only Tor traffic, no direct connection to our infrastructure) while sidestepping the reputation problem with Tor exit nodes. The bridge guard relay is operated by us, so customers needing protection against us specifically still need additional layers; the bridge solves the exit node reputation problem, not the trust-no-one problem.
We respond to legal process valid under the law of our operating jurisdictions according to documented internal procedures. Honest scope: we are not above the law in any jurisdiction we operate in. What we can produce in response to legal process is limited to what we actually have. We do not have customer identity documents (we never collected them), we do not have customer postal addresses (we never collected them), we do not have customer phone numbers (we never collected them). What we do have within retention windows: anonymised SMTP logs (7 days), authentication logs (7 days), abuse handling records (30 days), payment records in Monero or other cryptocurrency form (kept for accounting). We will challenge legal process that appears unlawful, disproportionate, or outside the issuing authority jurisdiction, but we will not engage in unlawful obstruction. Customers needing absolute protection against legal process from a specific jurisdiction should not host in that jurisdiction; our datacenter locations are documented and customers choose their jurisdictional exposure at signup.
Telegram conversation establishes contact email, PGP public key, payment method (Monero recommended), and datacenter location preference. Bridge guard relay provisioned within 48 hours. Onion address delivered via PGP-encrypted email. First annual audit report delivered within 12 months of order. Cancel anytime; no minimum term.
# Median Telegram response: 12 minutes during operating hours