What Katafract can see

This page exists because the answer to "what does this service do with my data" should fit on one screen. Below is a per-module table of what Katafract holds, what we do not, and why. Each row links to the module page if you want the full mechanism.

We do not distinguish "we could collect this but promise not to" from "we are architecturally unable to collect this." Where the distinction matters, we say so in plain language.

Data posture, per module

Module	Can see	Cannot see
ShroudNet	Node-to-node control traffic (ours) Which of our own servers are online Aggregate infrastructure metrics	Customer VPN packets (they never enter this mesh) Customer DNS queries
WraithGate	Your current IP during handshake Aggregate bandwidth counters per peer Peer provisioning metadata (region, public key, internal subnet)	Packet contents Destination IPs or hostnames Which customer connects to which customer (peer-to-peer is blocked)
Haven	Aggregate query-and-block counts per node A query while it is in memory being answered	Per-customer query history (disabled on every node) Source IP → query pairs
Shards	Ciphertext blobs + their sizes + upload times Per-bucket object count and total bytes Aggregate read/write rates	Plaintext of any Vaultyx file (we do not hold the key) Filenames or folder names Relationships between chunks across files
Sigil	A hash of your subscription token and the tier it belongs to Store transaction identifier, for receipt verification Aggregate quota counters (bytes used, peers provisioned)	Your email address or name (not collected by consumer apps) Device identifiers (IDFA, IDFV, advertising IDs) Which Apple ID or Google account is behind a subscription
Control plane	Subscription state (tier, expiry, token hash) Peer provisioning records (region, public key, created-at) Fleet health and capacity metrics Audit log of provisioning events	Customer packet contents DNS queries Plaintext Vaultyx data

The honest edges

A few cases do not fit neatly in the table. We call them out explicitly so that the summary above stays trustworthy.

Payment processor metadata

When you subscribe, the payment flows through either the App Store, the Play Store, or Stripe depending on the product. Those processors are Katafract's vendors. They know your billing identity because billing systems require it. We receive a transaction identifier from them, not your full billing record. We retain the transaction identifier so we can respond to refunds and chargebacks.

Support email

If you email hello@katafract.com, we see your email address and the contents of your message, because that is what email is. Support history is retained in our ticketing system for as long as we can reasonably need to answer follow-ups. If you want a support answer without your email being associated with your subscription, send the mail from a separate address — there is no server-side join that ties them together on our end.

Content delivery and DNS on the public web

This website — the one you are reading — is served behind Cloudflare. Cloudflare sees the IP that requested each page. That is normal CDN behavior and it is disclosed here for completeness. The website does not track you; we do not run analytics SDKs on it.

Compelled disclosure

We publish a warrant canary that we update quarterly. The practical limit of a compelled disclosure is set by what we hold: our response to most lawful requests for customer content will, honestly, be that we do not retain the data requested. Where we do retain data — subscription state, store transaction identifier, a peer's provisioning timestamp — we will respond to a properly scoped legal order, and we will challenge overbroad ones.

Third-party subprocessors

These are the only third parties that receive any data in the course of normal operation:

• Apple App Store & Google Play — receipt validation, subscription lifecycle.
• Stripe — payment processing for web-purchased subscriptions.
• Cloudflare — CDN and DNS for our public websites.
• Quad9 and Cloudflare (for DNS-over-HTTPS) — upstream resolvers for Haven. They see queries originating from our nodes, not from you.
• Our VPS and server providers — the underlying physical infrastructure for our nodes. They can see the node exists. They do not have access to the traffic passing through a running kernel.

We do not share data with advertising networks, data brokers, or analytics vendors, because we do not integrate with any.

What this means for you

The goal of this page is a specific one: if you are deciding whether to trust us with your traffic or your files, you should be able to read the table above, check our module pages to verify the mechanism, and reach a conclusion without needing to take any claim on faith. If that exercise surfaces anything we have stated here that does not hold up under inspection, tell us — we will fix the page, the product, or both.

Back to all modules.