Privacy is yours.
We built the proof.

Vault — your notes, passwords, and documents — is stored only on your device, behind your biometric gate. 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.

End-to-end encryption protects what you say, not who you're talking to. Veil's relay can still see who is contacting whom — the room membership itself isn't hidden, even in an encrypted conversation. Genuine metadata privacy ("sealed sender" or similar) would mean replacing how the underlying protocol routes messages, not a setting we can flip — we've scoped what that would actually take and it's a major undertaking, not something we're claiming is solved. What we have fixed: the messaging server's access log used to record your source IP address alongside your account identifier on every request, with no size or retention limit at all, growing forever. Both are now fixed — the access log no longer records IP addresses at all, and everything else logged is hard-capped and auto-rotating. What remains: the server still has to know which room you're in and who else is in it, to deliver your messages to the right people. That's a real, ongoing limitation, not one we're claiming to have solved.

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. Everything lives inside your device's own sandboxed storage, unlocked only by your biometric 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.

We've built and tested a real WireGuard VPN tunnel — genuine handshake, genuine encrypted traffic, confirmed working on a physical device, not a mockup. It is an early-stage spike, by design: it isn't included in this build, has no user-facing on/off control yet, and we haven't finished auditing what the VPN server itself logs. We're not switching it on for anyone until all of that is true and reviewed.

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.

Calls use WebRTC with DTLS-SRTP encryption directly between your device and the person you're calling. There is no server in the call path that can decrypt the audio or video — our TURN relay, used only when a direct connection isn't possible, forwards encrypted packets it cannot read itself. That part is end-to-end encrypted — the same real guarantee messaging has. What calls don't yet have is messaging's device-level cryptographic identity: every Matrix conversation is tied to registered device keys for each Veil ID, while a call's signalling is authenticated only by a shared app secret, not by your specific identity. We also don't yet expose a way to manually verify device identity for calls (or messages) in the app — a real, open gap, not glossed over here.

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.