Privacy is yours.
We built the proof.

Vault — your notes, passwords, and documents — is stored only on your device, protected by your Veil PIN (with biometrics or a recovery key as alternates). It is never uploaded or transmitted anywhere. Messaging and calls both have real end-to-end encryption, verified on real devices: content is unreadable to Veil's own infrastructure, not just to outside observers.

When you message someone on Veil, your messages — text, reactions, photos, videos, and voice notes — are end-to-end encrypted: content is unreadable to Veil's own infrastructure, not just to outside observers. This was built, broken, rebuilt, and verified across real testing on physical devices before we were willing to say so here.

Voice and video calls use WebRTC with DTLS-SRTP encryption between the devices in the call. If a direct connection cannot be made, a relay forwards the encrypted traffic without having the key needed to read the audio or video.

There is an important distinction between call encryption and call identity. Messaging is tied to registered device cryptographic keys. Call signalling currently uses a shared Veil application secret rather than a cryptographic identity belonging specifically to your device. That means the content of a call is strongly encrypted, but the identity assurance around the call is currently weaker than it is for messaging.

Veil also does not yet provide manual device verification for calls. When a relay is needed, our relay provider retains ordinary connection metadata such as relaying IP, transport type, session timing and data volume. It does not retain or inspect call content.

End-to-end encryption protects what you say. It doesn't hide the fact that your Veil ID and another Veil ID share a conversation — Veil's relay necessarily processes that much to route encrypted messages to the right people, the same way any messaging service has to know where to deliver a message. That's routing metadata, not knowledge of who you are: a Veil ID isn't inherently linked to your real-world identity, and the room-membership fact alone doesn't tell us that.

Vault — your secure notes, passwords, and documents — never leaves your device. There is no upload and no server-side copy — nothing for Veil to store, read, or lose. Once you set up a Veil PIN, everything in Vault is encrypted with a real Data Encryption Key (DEK) that only your PIN or your recovery key can unlock — not just gated behind a lock screen, genuinely unreadable without one of those two. Biometrics are an optional, faster way to unlock the same key, never a requirement. If you haven't set up a Veil PIN yet, Vault falls back to your device's own Face ID/passcode gate.

Sending, receiving, and viewing transaction history in Veil Wallet all use real interface code. What isn't real yet: live payment infrastructure. Balances and the VLT token itself are simulated while we finalise partnerships with payment providers. No real money moves through Wallet today.

Veil Browser blocks requests to a known list of tracker and analytics domains before they load, and automatically rejects cookie-consent banners from major providers. Third-party cookies and on-device storage are disabled for every page you visit. No browsing history is saved — not on your device, not on our servers. Fingerprinting resistance now covers canvas, WebGL, AudioContext, font-enumeration, installed plugins, and browser language — the deliberate exception is screen resolution, left alone since spoofing it risks breaking real responsive layouts for limited privacy benefit on a mobile device.

When you use the AI Assistant, your message and limited relevant context are sent through a Veil-run proxy to Anthropic's Claude. That context can include upcoming Tasks and Calendar events and coarse weather information where you have already allowed location access. Anthropic is not sent your Veil ID.

Separately, Veil stores the conversation transcript against your Veil ID so the assistant can preserve context. Conversation history is limited to the most recent 60 messages and expires after 90 days. Starting a New Session deletes the stored conversation.

The assistant can propose creating a Task, Calendar event or Note, but nothing new is saved until you confirm it.

Notes use an on-device-only privacy model. They can be linked to Tasks or Calendar events, but the Note itself and those local relationships remain on the device.

The trade-off is straightforward: because Notes are not uploaded, they do not currently follow you to another device.

When you ask Discover about a place, Veil sends the place information needed for that request through its AI proxy to Claude. For Nearby, this can include an approximate town or neighbourhood-level location. Your Veil ID is not included.

Discover content is generated rather than taken from a checked historical database, so specific historical claims should not be treated as guaranteed facts.

When a suitable real-world photograph is available through Wikimedia Commons, the app can retrieve it directly from Wikimedia and display the photographer and licence information.

Veil VPN encrypts traffic between your device and your selected region using WireGuard. London, Amsterdam, Frankfurt and New York are four logical regions, each backed by a primary and a same-region backup server. We have physically verified real handshakes, the expected exit IP and location, DNS travelling through the protected path, region switching, and transitions between Wi-Fi and mobile data.

If the server you're connected to becomes unreachable, your traffic is not exposed to the open internet — it stays blocked, and Veil automatically reconnects you through a healthy backup server in the same region, typically within seconds. This is physically proven end-to-end, including with the device locked and Veil running in the background the whole time. Veil never silently moves you to a different region: if every server in your chosen region is unreachable, your traffic stays blocked until a server in that region recovers.

Two things remain important enough to state plainly.

First, this protects you specifically while Veil's VPN connection is running. It doesn't yet cover every failure mode: if the VPN connection itself is stopped or crashes outright, the device can currently fall back to your normal internet connection rather than staying blocked. A stricter setting that closes this gap too has been built and tested separately, but it is not the default protection shipped today.

Second, we have not yet completed the same independent audit of connection-level logging on Veil's own VPN infrastructure that we have carried out for some other parts of the service. Until that work is complete, we treat the server-side logging posture as unverified rather than assuming it is clean.

When you get a Veil notification, it says someone sent you a message — never what the message contains. The actual content stays encrypted on your device and is never included in what we send to Apple's notification service.

Blocking someone stops them at the server level — Veil's messaging server is told to ignore them for your account, the same mechanism the underlying protocol provides for this, not something we bolted on client-side that a modified app could ignore. Reporting a user works the way privacy-respecting messaging apps have to: since we can't read your messages, a report only ever includes what you explicitly choose to attach — you see exactly what would be sent before you send it, every time.

Veil Mail follows the same zero-access model ProtonMail itself uses, verified against our real production server, not just designed. Mail between two Veil users is encrypted on your device before it's ever sent — our server never holds a readable copy, not even momentarily, the same guarantee messaging has. Mail arriving from outside Veil (Gmail, iCloud, Proton, anyone) is encrypted the instant it reaches our server, before it's written to storage — our server holds it in plaintext only for the fraction of a second the delivery itself takes, never at rest. Mail you send to someone outside Veil is protected in transit only (TLS), readable at their own provider the same way it would be anywhere else — a physical property of how ordinary email works, not a gap in our effort, and the same limitation ProtonMail states plainly for its own outbound mail.