How Sendant is built — and what we won't claim
Updated 11 July 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.
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 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 both clients — native library on Android, 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 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. 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.
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.
- 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.
Check the claims yourself
Inspect the headers, compare the safety numbers, verify the APK signature — the point of this page is that you can.
Open web app Browser trust model Verify the APK