A threat model is a list of the bad things you defend against and a list of the bad things you do not. Most consumer security products quietly assume the second list does not exist, which is convenient until something happens and the product is found wanting. Sudo's threat model is published, audited, and updated whenever the product changes. This post is the long version, in plain language.
If you are deciding whether Sudo fits your situation, this is the document to read. Not the marketing pages.
Why threat models matter
Security is meaningless without a model. "Sudo is encrypted" is true and almost useless on its own. Encrypted against whom? With what assumptions about the participants' devices? Using which cryptographic primitives, with which key management, against an adversary with which budget and which legal access?
Without specifying the model, a security claim is roughly a vibe. With the model specified, the claim becomes testable and the user can decide whether the assumed adversary is the one they are actually worried about. Signal does this well. Telegram does not. Most other messengers fall in between.
In scope: things we actively defend against
The following adversaries are part of the design. If we fail against them in production, we treat the failure as a bug and we patch it.
A passive network observer — your ISP, a coffee shop wifi sniffer, a transit provider, a national observation point — sees only TLS-wrapped traffic between your device and our relays. The contents are AEAD-encrypted under MLS keys we do not hold. Such an observer can learn that you use Sudo, that you communicated for some duration, and rough volumetric metadata. They cannot learn message contents, group memberships, payment amounts, or wallet associations beyond what your wallet itself reveals on chain.
A malicious or compromised relay is part of the model. Sudo Labs operates the default relay set, but the protocol is designed to assume the relay is hostile. The relay never sees plaintext message contents, never sees group keys, never sees voice payloads in decryptable form, and cannot impersonate users (because every message is signed by the sender's wallet). Compromise of the relay leaks metadata and does not leak content.
A compromised contact — an account in a group whose wallet has been taken over by an adversary — is part of the model up to the point that the compromise is detected. The adversary sees current and future messages in the rooms that wallet is a member of, can post as that wallet, and can be removed from the rooms by the room's moderators. Past messages remain protected by forward secrecy: the adversary cannot retroactively decrypt anything sent before the compromise. After removal, the adversary cannot decrypt anything sent after the compromise either, by post-compromise security.
A lost or stolen device, with the wallet still installed, is part of the model. Local message storage is encrypted at rest with a key derived from your wallet signature; an attacker without the wallet cannot read the local store. If the wallet is itself unprotected (no biometric lock, no PIN), the attacker can sign as you until you revoke the device from another. We strongly recommend using a wallet with biometric authentication.
A subpoena to Sudo Labs is part of the model. We respond to lawful requests by handing over what we have, which is metadata only — never message content, never decryptable media, never voice recordings. The transparency report on the security page lists the categories of data we have ever produced, in aggregate.
Out of scope: things we cannot defend against
The following adversaries are out of scope. If you are at risk from them, Sudo will reduce your exposure compared to a non-encrypted messenger but it cannot eliminate it.
A nation-state with legal authority to compel a hardware vendor or an operating system vendor is out of scope for any consumer messaging app. If a state can force Apple or Google to push a targeted update to your phone, no messenger can defend against it. We recommend hardening at the OS level — Lockdown Mode on iOS, equivalent profiles on Android — and keeping the messenger threat model in the right size.
Physical coercion of you or your contacts is out of scope. If somebody has you in a room and is asking you to unlock your phone, the messenger cannot help. The duress-PIN feature on the roadmap is a partial mitigation but should not be relied upon in true coercion settings.
OS-level malware on your device is out of scope. A keylogger sees everything you type. A screen recorder sees everything you read. Sudo's encryption protects you against threats above the OS layer; it cannot protect you against threats at or below it. Use a malware-clean device.
Supply-chain attacks on Sudo's dependencies are partially in scope and partially out. We pin all dependencies, sign every build, publish reproducible build artifacts, and run automated dependency review. We have no defence against a successful targeted compromise of one of our build pipelines that nobody notices in time. Reproducibility is the user-side defence.
A subpoena issued to a wallet you control is out of scope by definition. Sudo cannot intervene between you and a court order that compels you to sign a message. Defensive posture for high-risk users involves multisig wallets and operational separation, not the messenger.
The hard cases
Some scenarios fall in the grey zone. We want to be honest about them.
Lost keys. If you lose your wallet, you lose your Sudo identity. We have no way to recover it for you. Our recommendation — strong, repeated — is to use a social-recovery wallet or a multisig signer for any account whose loss would matter to you. The delete-account page describes the recovery options we do support.
AI-generated impersonation. The cost of generating a convincing fake voice clip of someone you know is approaching zero. Sudo signs every voice and video message with the sender's wallet, which means you can verify the sender cryptographically — but you have to actually look at the verification badge before you trust an audio clip. We are working on UI that surfaces verification more prominently, but we cannot make users vigilant for them. Treat unsolicited urgent audio messages from contacts the same way you would treat an unsolicited urgent email from a relative claiming to be stranded abroad.
Government data requests under foreign laws. Sudo Labs is a Singaporean company with subsidiaries in the US and the Cayman Islands. We respond to requests from these jurisdictions through proper legal process and only for data we hold. Requests from other jurisdictions are evaluated under MLAT or equivalent treaties. The transparency report publishes counts and categories.
Validator collusion. The validator network is designed to make collusion expensive (hidden identities, random selection, slashing for incorrect votes), but it is not impossible. A determined adversary that controls a quarter of the active validator stake and can correctly predict random selection has a non-trivial chance of swinging individual disputes. We track the cost of such an attack in the protocol parameters and tune them to keep it well above the value at risk in a typical escrow.
Comparison to nearby messengers
Briefly, because comparisons are useful and because we believe in them.
Signal is, in our opinion, the closest design philosophy. Signal protects message contents with rigorous E2EE, treats metadata reduction as a first-class concern, and publishes a clear threat model. Signal is centralised on a single operator and uses phone numbers as identity. Sudo is non-custodial on identity (your wallet) and decentralised on dispute resolution (the validator set). Both are good fits for different threat models.
Telegram is the worst-case comparison. Telegram's default chats are not end-to-end encrypted. Group chats are never end-to-end encrypted. The threat model is "trust Telegram", which is a viable choice depending on your circumstances but should not be confused with the threat model of an actually encrypted messenger.
WhatsApp encrypts message contents with the Signal protocol but stores extensive metadata centrally and integrates with Meta's identity graph. Sudo holds neither.
Matrix is closest in spirit on the federation question. Matrix is more federated than Sudo (any homeserver can join), and Sudo is more cryptographically rigorous on group encryption (we use MLS, Matrix uses Olm/Megolm with known scaling caveats). Both are reasonable choices for organisations with technical staff.
Auditing your own threat model
The most important advice we can give is this: write down your own threat model before you choose a tool.
Who do you actually need to defend against? An ad-network advertiser? A controlling spouse? A national security service? A sophisticated cybercriminal? A jealous coworker? A subpoena? Each adversary has different capabilities, different budgets, different legal access, and demands different defences.
Once you have your model written down, evaluate every tool against it — not against a generic "encrypted" promise. Sudo's threat model is good for users worried about platform overreach, censorship, content surveillance, payment surveillance, and identity loss to a centralised authority. It is not good for users worried about state-sponsored physical surveillance or OS-level compromise.
If your situation is the second category, please use a security professional and a hardened device, not a consumer app. We mean that.
Where to go from here
The full technical version of this document, with citations to the underlying RFCs, our published audit reports and our ongoing research, lives in the security pages and the whitepaper. Vulnerability reports go to the security email on the security page; we run a paid bounty program through Immunefi and we acknowledge every responsible disclosure publicly.
Thanks for reading. Threat models are not glamorous, and we are grateful that you cared enough to read this far.