Encrypted messenger security: how Sendant is built — and what we won't claim
Updated 18 October 2026
The architecture, the cryptography, the threat model, and a plain-language list of what's done, what's hardened, and what isn't finished yet. Written to be checked, not believed.
Security at a glance
Short answer
Sendant encrypts message content on your device with X3DH plus Double Ratchet — the same primitives Signal uses — and the servers hold only ciphertext. An independent audit has not been completed yet, the source code is private, and network-level metadata such as your IP address is not hidden.
- Keys Generated on your device and never sent to a server; safety numbers verify the other end.
- Servers see Ciphertext, plus what any server sees to route a message. Not message content.
- Not claimed Not audited yet, not open source, not a mesh app, no IP-address hiding.
In one paragraph: Sendant is an end-to-end encrypted messenger with no phone number, no email, and no account. Your identity is a cryptographic key generated on your device. Messages are encrypted on-device with X3DH + the Double Ratchet — the same primitives Signal uses — by a single Go implementation shipped native on Android and iPhone and as WebAssembly in the browser. Servers store and forward ciphertext only. It is not yet independently audited, and this page says so in the same breath as everything else.
Identity: a key, not a name
There is no registration. Creating an identity generates key material on your device; connecting with someone means exchanging an invite link or scanning a code — discovery is explicit and consensual, because there is no phone-number or email directory to mine. No identifier also means less to subpoena: the server has no account record that maps to a person.
Message encryption
One shared crypto core
X3DH establishes each conversation's keys; the Double Ratchet advances them with every message, giving forward secrecy (a stolen key can't decrypt past messages) and post-compromise recovery (sessions self-heal after a key exposure). The implementation is written once in Go and compiled for every client — a native library in the Android and iPhone apps, WebAssembly in the browser — so there is no second implementation to drift. Why that matters in a browser specifically is treated honestly and at length on the browser trust-model page.
Sealed-sender-style envelopes
Messages travel in envelopes whose sender header is opaque to the mailbox server: it can deliver to a recipient without reading who the sender is inside the envelope. Combined with ciphertext-only content, the server's view of a conversation is deliberately impoverished.
Verifiable safety numbers
Each conversation has a safety number derived by SHA-256 from both parties' full identity key bundles — twelve 5-digit groups, identical on Android, iPhone and web. Compare it with your contact over any channel we don't control and you have personally verified there is no machine-in-the-middle, ours included.
What servers can and cannot see
Delivery today is an encrypted store-and-forward mailbox: if your contact is offline, ciphertext waits and delivers when their device reconnects (the full delivery ladder, including what's still roadmap, is documented here). The mailbox holds encrypted envelopes with expiry — not message text, not a contact graph, not an account profile. Voice and video calls are end-to-end encrypted WebRTC (the browser client makes voice calls only, and only while the tab is open). Call media takes the most direct path available, which means the person you are calling can see your network address — the same as any peer-to-peer call. A "hide my IP during calls" setting, in Settings under Privacy & Security, routes your media through our relays instead, so the other party sees the relay's address and never yours; with it on, a call for which no relay is reachable fails closed rather than quietly leaking your address. Installs that predate this change keep relay routing until you choose otherwise.
Your device
Holds- Your private identity key
- Session keys for each conversation
- Message history, encrypted at rest
- Plaintext — this is where encryption happens
Sendant mailbox
Holds- Encrypted envelopes, with an expiry
- A routing key per device
- Message text or media
- The sender inside the envelope
- A phone number, email, or account
- A contact list or social graph
- That a device connected, when, and from which network address
Their device
Holds- Their private identity key
- The only other copy of the session keys
- Plaintext, after decrypting locally
- A safety number to verify it was you
The service infrastructure is hardened the boring way: strict transport security and content-security policies on the web properties, request timeouts and connection caps against resource-exhaustion attacks, per-IP and fleet-wide rate limits, and logging that excludes message content, tokens, and IP-to-identity joins.
Keys at rest
- Android: key material is protected by the platform Keystore, hardware-backed where the device supports it.
- iPhone: the identity secret and the key that encrypts local message history are iOS Keychain items flagged this device only — protected by iOS data protection, never synced through iCloud Keychain, and not restored onto another device from a backup. The privacy policy lists exactly what the Keychain holds.
- Browser: identity and session state are encrypted at rest under an AES-256-GCM key created non-extractable in WebCrypto and held in IndexedDB — it cannot be exported even by same-origin code. Scope and limits of this are spelled out on the browser page.
Honest status
- Not independently audited yet. An external audit is planned and is a hard gate before we promote Sendant in privacy communities. We do not use the word "audited" until it is true.
- Source code is private and stays private. Sendant is not open source, and we never claim it is. What we do publish is the architecture, threat model, and protocol design — plus a signed, hash-verifiable Android APK you can check yourself. You verify Sendant by its documented design and signed builds, not by compiling our source.
- Platforms: Android, iOS, and the browser. The iOS app shipped in August 2026 and is new — we do not claim it has the field history the Android build has.
- Delivery paths: encrypted mailbox ships today; peer-to-peer and relayed message delivery are roadmap and labeled as such wherever we mention them.
- The browser tier has inherent limits that no web app escapes; we document them rather than wave at them — see the steelmanned browser page.
Common questions
What encryption does Sendant use?
X3DH key agreement and the Double Ratchet — the same well-studied primitives Signal uses. The implementation is written once in Go and compiled for every client: a native library in the apps, WebAssembly in the browser, so there is no second implementation to drift. Messages are encrypted on your device; our servers only ever store and forward ciphertext.
Does Sendant have access to my messages or contacts?
No. Identity keys are generated and held on your device, and there is no account, phone number, or email to tie them to. Message content is end-to-end encrypted before it leaves the device, envelopes carry a sender header the mailbox cannot open, and there is no server-side contact list or social graph to read in the first place.
Has Sendant been independently audited?
Not yet, and we say so in the same breath as everything else on this page. An external audit is planned and is a hard gate before we promote Sendant in privacy communities — we do not use the word "audited" until it is true. Until then the claim stays limited to what is defensible: Sendant is built on X3DH and the Double Ratchet, with one implementation shared by every client.
How do I report a security vulnerability in Sendant?
Email privacy@sendant.io with "SECURITY" in the subject line. Reports go to the people who ship the fixes. Reproduction steps help; other people's message content does not belong in the report.
Related privacy tools
Private messaging is one piece of a smaller footprint. Two sibling products from the people behind Sendant cover the rest of your inbox. Each is a separate product with its own privacy policy; Sendant shares no data with either.
Emcognito — private email aliases for signups that still demand an email address
Give every service its own alias, keep your real inbox out of breach lists, and switch an alias off the moment it starts attracting spam.
FolioInbox — one inbox for every business domain you own
Email hosting for people running more than one business: every domain in a single inbox, replies sent from the matching address, and each domain signed with its own DKIM key.
Check the claims yourself
Inspect the headers, compare the safety numbers, verify the Android APK signature — the point of this page is that you can.
Open web app Browser trust model Verify the Android APK