Threat model
Who can see what, and what stops them
A threat model is only useful if it names the adversaries it loses to as clearly as the ones it beats. Each row below lists what that adversary sees, what it cannot reach, the defence in place, and what remains possible anyway.
PrivaMesh is designed against an operator who wants your data, a chain observer reading everything public, and an impostor trying to intercept a contact add. It is weakest against a global timing analyst and offers nothing at all against a compromised device.
| Adversary | Sees | Cannot | Defence | Still possible |
|---|---|---|---|---|
| PrivaMesh, the operator | That an account paid for a send, and when | Read messages, learn recipients, list your contacts, or reconstruct history | No account database or message store; blind tokens unlink payment from sending | We could be compelled to show that some account sent something at a given time |
| The RPC provider | Your IP address, request timing, the transactions you submit | Decrypt anything, or tell which one-time address belongs to whom | The endpoint is swappable and self-hostable | A logging provider builds a network-level picture of when you are active |
| A chain observer | Padded ciphertext, one-time addresses, exact transaction times | Read content, or link two messages in the same conversation | Stealth addressing, fixed padding buckets, optional cover traffic | With cover traffic off, your activity pattern over time is fully visible |
| A global timing analyst | Correlated activity across the whole network at once | Decrypt, or link addresses cryptographically | Cover traffic at random 3-10 minute intervals, when enabled | This is the adversary we defend against least well; an observer of the entire network with unlimited retention is outside what any per-message design fixes |
| Someone holding your unlocked phone | Everything: plaintext, contacts, keys | Recover messages already deleted by the ratchet | Keychain storage behind Face ID or Touch ID; forward secrecy limits the past | Device compromise is total for anything currently on the device |
| Someone who has your recovery phrase | Your identity, and can impersonate you going forward | Read your past conversations - those keys no longer exist | The phrase never leaves your device and is never transmitted | There is no revocation. If the phrase leaks, the account is theirs too |
| A malicious contact | Everything you send them, and can screenshot or forward it | Reach anyone else you talk to, or read other conversations | Blocking, and per-conversation key separation | No cryptography prevents the person you are talking to from being untrustworthy |
| An impostor during contact add | Nothing, if verification succeeds | Substitute their key for a contact whose bundle is signed on-chain | Wallet-signed prekey bundles published on-chain, verified by signature not by directory | You still have to confirm you added the person you meant to add |
| Apple | That your Apple ID bought a subscription | See messages, contacts, or link the purchase to your sending activity | Blind tokens sit between the purchase and every send | Apple knows you are a PrivaMesh customer, which is unavoidable on iOS |
| A network-level censor | That you reached a Solana RPC endpoint | Read or selectively drop individual messages | RPC endpoints are swappable, including to ones you run | Blocking Solana or every RPC blocks delivery entirely |
What this model assumes
That the cryptographic primitives hold: X3DH, the Double Ratchet, AES-256-GCM and, on iOS 26, ML-KEM-768. That your device is not already compromised. That you verify the contact you are adding is the person you intended. If any of those fail, the rest of the design does not save you.
It also assumes our implementation of those primitives is correct, which is exactly the assumption an independent audit would test and which has not happened yet. For the full list of what is not covered, see known limitations.
Frequently asked questions
What is PrivaMesh worst at defending against?
A global adversary who watches the whole network continuously and keeps everything. Cover traffic raises the cost of timing correlation but does not defeat an observer at that scale, and the chain keeps a permanent record for them to work against.
If my device is seized, what is exposed?
Everything currently on it: plaintext, contacts and keys, unless it is locked and the attacker cannot get past Face ID. Forward secrecy limits the damage to what has not yet been deleted by the ratchet - old messages are already unrecoverable.
Can PrivaMesh be forced to hand over my data?
It can be asked. What exists to hand over is that an account paid for a send at a given time. There is no message content, no recipient, no contact list and no account record, because none of those are stored.
Does a VPN help?
Yes, against the RPC provider and a network-level observer, which are the two adversaries that see your IP. It does nothing about what is written to the chain, which is already unreadable.