What encryption does Sendant use?

X3DH key agreement and the Double Ratchet — the same well-studied cryptographic primitives Signal uses — implemented once in Go and shipped as a compiled native library on Android and as WebAssembly in the browser, so both clients run the same implementation. Messages are encrypted on your device; 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 — 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 use a sealed-sender-style header the mailbox cannot open, and there is no server-side contact list or social graph to read.

Has Sendant been independently audited?

Not yet, and Sendant says so plainly. An independent audit is planned and treated as a hard gate before promoting the product in privacy communities. Until then the claim is limited to what is defensible: it is built on X3DH and the Double Ratchet, with the implementation shared between the native and web clients.

How do I report a security vulnerability in Sendant?

Email privacy@sendant.io with SECURITY in the subject line. Reports are read by the people who ship the fixes. Please include reproduction steps; please do not include other people's message content.

Security overview

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 calls are end-to-end encrypted WebRTC. A default-on "hide my IP during calls" setting — on Android and in the browser — forces call media through our relays so your network address is not exposed to the other party; if no relay is reachable, the call fails closed rather than quietly leaking your address.

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 and the browser today. No native iOS app (the web client covers iPhone).
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.

Found a vulnerability? Email privacy@sendant.io with "SECURITY" in the subject. Reports go to the people who ship the fixes. Reproduction steps help; other people's message content doesn't 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