Threat model.
Honest about what we can and can't protect.
A privacy product is only as honest as its threat model. This page lists the adversaries Onym is built to resist, the adversaries it is not, and what it does and does not guarantee against each.
Where copy elsewhere on this site disagrees with this document, this document is right and the copy is wrong. Tell us at lead@onym.app.
Where trust lives
Onym moves what a traditional messenger keeps inside one server out into a small set of replaceable, mostly-blind parties. The same six pieces of data exist either way; what changes is who can see them.
How to read this
Onym is end-to-end encrypted group messaging where group state lives on a public ledger (Stellar / Soroban) and a relayer pays the on-chain fees so users don't need a funded account. Identity is generated and stored on device; the network ties of one identity to another are mediated by zero-knowledge proofs of group membership.
That architecture removes a class of attacks (a single operator with kill-switch authority over your account; a server that holds plaintext or a recoverable social graph). It does not remove every attack. The list below is what we believe the architecture actually delivers, written as plainly as we can manage.
Adversaries
In scope means we make explicit guarantees and design against this adversary. Partial means we resist some attacks in this category but not others. Out of scope means we do not claim protection — and you should know why before you trust Onym for that case.
- Relayer operator · in scopeSees ciphertext + timing. Cannot read, impersonate, or de-platform.
- Malicious group member · in scopeCannot impersonate, exceed role, or rewrite history beyond governance.
- Passive on-chain observer · in scopeCannot tie on-chain identity to a human or read content.
- Active observer + timing · partialSingle-event linkage resisted; long-run intersection is not.
- Stellar validators · partialCannot read content; can refuse inclusion, observe IPs.
- Global passive surveillance · out of scopeNo padding, mixing, or cover traffic.
- Device-level adversary · out of scopeEnd-to-end encryption ends at the ends.
- Quantum adversary · futurePre-quantum primitives today; PQ migration on roadmap.
The relayer is the service that submits a user's signed Stellar transactions and pays the fees. It sees ciphertext and connection metadata. We design assuming it is untrusted, possibly malicious, and possibly logging.
Anyone admitted to a group is trusted to read that group's messages. We design against them gaining capabilities outside the group's governance rules — impersonation, history rewriting, exceeding their role.
Anyone reading the public Stellar ledger. We design assuming the ledger is public — group operations are visible, but they should not directly identify which human controls which on-chain identity.
An observer who watches the ledger and correlates with other signals (relayer logs, network probes, app-publish timing). We resist single-event linkage but not patient long-run intersection attacks.
The validators that order and confirm transactions, and the ISPs that carry the packets. They cannot read message content. They can refuse to include transactions, observe your IP, and (in extremis) coordinate to reorder consensus.
An adversary who can observe most or all internet traffic worldwide and run patient timing correlation. Defeating this would require Tor-style mixing, padding, and cover traffic — which Onym does not currently provide.
Compromised phone, OS-level malware, screen recording, hostile keyboard, jailbreak. End-to-end encryption ends at the endpoints; if your endpoint is owned, your messages are owned.
Onym uses pre-quantum primitives (BLS12-381, secp256k1, Ed25519, X25519). A cryptographically relevant quantum computer would defeat these. Migration to post-quantum primitives is future work, not present-day protection.
Guarantees, by adversary
For each in-scope adversary, what Onym guarantees and what it does not. The "does not" rows matter as much as the "does" rows.
Against the relayer operator
What it cannot do
- Read message plaintext. Messages are end-to-end encrypted between members; the relayer sees ciphertext only.
- Impersonate a user on chain. Stellar transactions are signed on device; the relayer cannot forge a signature.
- Rewrite group state. Group governance is a Soroban contract; the relayer is not authorized to act in it.
- Permanently de-platform you. The transport is open; users can switch relayers, run their own, or use multiple.
What it can still see or do
- Connection metadata: your IP, when you connect, message size, frequency, which contract a transaction targets.
- Refuse to relay your transactions. A single relayer can deny service to a single user; the user's recourse is to switch.
- Profile a user over time if the user always uses the same relayer from the same IP without rotation.
- Correlate ciphertext relay timing with on-chain confirmation timing for the transactions it submitted.
Against a malicious group member
What they cannot do
- Decrypt messages from groups they are not in.
- Impersonate another member inside the group. Each message is signed by the sender's per-group key.
- Exceed the role granted by the group governance contract. Admit, remove, and post permissions are enforced on chain.
- Silently rewrite group history beyond what governance permits.
What they can still do
- Read everything sent in the group while they are a member. End-to-end encryption is between endpoints, including theirs.
- Screenshot, copy, or otherwise leak content out of band. No cryptography defends against voluntary disclosure.
- See the full membership list of the group (a property of group chat, not a bug).
- Probe sender anonymity within a small group. ZK proofs hide which member sent a message; in a 3-person group, the search space is small.
Against a passive on-chain observer
What they cannot do
- Read message plaintext. No plaintext is ever placed on chain.
- Identify the human behind an on-chain identity from the chain alone. Identities are unlinked from real-world identity by construction.
- Tell which member of a group sent a given group operation when ZK proofs are used in place of a member identifier.
What they can still see
- That a group exists. That an operation occurred. When it occurred. How often operations occur.
- How many members a group has, within a small range, from membership operations.
- Which on-chain identities have transacted with which other on-chain identities, even if no real-world name is attached.
Against an active on-chain observer (with timing)
What they cannot easily do
- Link a one-off on-chain operation to a specific real-world user from the chain alone.
- Determine sender anonymity inside a large enough group when ZK proofs are used.
What they can do given enough time
- Correlate Onym activity with a particular IP if they also run, or coerce, a relayer.
- Run intersection attacks. If a particular user is online at a particular minute every day and a particular group operation occurs only on those minutes, the user and group can be linked over weeks.
- Observe activity bursts, group-size changes, and governance events as a usage profile, even without identity.
Against Stellar validators / network providers
What they cannot do
- Read message content. Nothing in plaintext is ever on chain or in flight.
- Forge signatures or modify governance rules. Soroban contracts are immutable code, executed by all validators.
What they can do
- Refuse to include transactions, slowing or denying delivery for specific accounts.
- Observe traffic patterns at the network layer (ISPs); know your IP transacts with Stellar.
- In extremis: coordinate to reorder or fork the chain. This is a property of using Stellar at all, not of Onym specifically.
What Onym does not protect against
Counterintuitively, this section earns more trust than any positive claim. We would rather be narrow than wrong. Six categories of threat live outside Onym's perimeter. The diagram below names them; the prose afterwards spells each one out.
Global passive surveillance
Timing, volume, and IP-level metadata are visible to anyone on the network path. Onym does not pad, mix, or route over Tor.
Compromised device
Malware, jailbreak, screen recording, or seizure with the screen unlocked. End-to-end encryption ends at the ends.
Out-of-band disclosure
A group member can screenshot, transcribe, or describe what they read. Cryptography is not a non-disclosure agreement.
OS-vendor surveillance
Apple, Google, and your hardware manufacturer have privileged access. They are not Onym's adversaries; they are part of your endpoint.
Coercion of you
A wrench costs less than a key. We protect against an adversary who cannot compel you in person; not from one who can.
Quantum adversary
Pre-quantum primitives (BLS, secp256k1, Ed25519, X25519). A relevant quantum computer defeats them. PQ migration is roadmap.
- Network-layer traffic analysis. Timing, volume, and IP-level metadata are visible to anyone running the relayer or sitting on the network path. Onym does not pad messages, mix traffic, or route over Tor. If your threat model includes a global passive observer, Onym alone is not sufficient.
- Group-size and group-existence leakage on chain. Group operations are public. An observer can see that group X has roughly N members and roughly M operations per day, even if they cannot read content or identify members.
- A compromised endpoint. If your phone is compromised — by malware, jailbreak, screen recording, or seizure with the screen unlocked — Onym cannot help. End-to-end encryption ends at the ends.
- Out-of-band disclosure. A member of a group can screenshot, transcribe, or describe what they read. Cryptography is not a non-disclosure agreement.
- OS vendor surveillance. Apple, Google, and your hardware manufacturer have privileged access to your device. They are not Onym's adversaries; they are part of your endpoint.
- Single-relayer denial of service. If you only have one relayer configured and it goes down or refuses you, you are offline until you switch. Onym is censorship-resistant in aggregate, not in any single connection.
- Statistical de-anonymization within tiny groups. ZK proofs prove "a member sent this" without saying which. In a group of three, an outside guess has a one-in-three baseline. Privacy in small groups is a function of group size, not of cryptography.
- Quantum adversaries (today). Our primitives are pre-quantum. A future cryptographically relevant quantum computer would defeat them. Migration to post-quantum primitives is on the roadmap; it is not in production.
- Coercion of you. A wrench costs less than a key. We protect against an adversary who cannot compel you in person; we do not protect you from one who can.
What we mean when we say "no operator with kill-switch authority"
You will see this phrase across the rest of the site. It is narrower than "no server to trust," which is what we used to say. The narrower claim is the one we can defend.
It means: no single party — not Onym, not a relayer operator, not a hosting provider — can unilaterally disable your account, take your conversations away from you, or de-platform you. Identity is on your device. Group rules are on a public ledger. Transport is open and replaceable. Removing any one party from the system does not end your access; you swap them out.
It does not mean there are no servers. Relayers are servers. Stellar validators are servers. ISPs are servers. They are visible in this threat model, and they are honestly accounted for above.
How this document changes
This is v0.0.1. It will be wrong in places we have not yet noticed. When we discover a defect, we update this page, bump the version, and link the change in the changelog. We do not silently revise.
If you are a security researcher who reads this and finds a gap, write to lead@onym.app. Disclosure that improves this page is the most useful disclosure there is.
v0.0.1 · 2026-05-08 · MIT licensed prose, like the rest of the project