Hard questions,
answered as honestly as we can.

The relayer is a server. We used to say “no server to trust”; we have walked that back. The honest claim is narrower: no single operator with kill-switch authority over your account, your conversations, or your group’s rules.

Identity is on your device, so there is no “Onym account” to disable. Group rules are a public Soroban contract on Stellar, not a database the operator can edit. For every in-group action — admit, remove, vote, role swap — the relayer is the sole on-chain signer: it wraps your ZK proof into a Stellar transaction, signs it, and pays the fee. You sign nothing, which is what keeps in-group actions from binding to a stable on-chain identity. The one exception is create_group at group creation, where the founder signs a Soroban auth entry; that is the deliberate, single moment a user-bound signature touches the chain. If a relayer denies you service, you switch to another or run your own. Read the per-party breakdown on the threat model page.

It doesn’t never leave. Some metadata is necessarily public.

What stays local: identity (BIP-39 phrase), private keys, your contacts, your message history. What goes on chain: group operations — admit, remove, governance votes — submitted with a zero-knowledge proof that does not reveal which group member acted, but does reveal that the action happened, when, and which group it happened in. What the relayer sees: ciphertext, message size, timing, your IP.

If your threat model includes a global passive surveiller running timing correlation across the whole internet, Onym alone is not sufficient. The threat model says so plainly.

Encrypted blobs, the timing and frequency of your relay requests, your IP (unless you bring your own privacy network), and which Soroban contract a transaction targets. It does not see message plaintext, which group member sent a given message, or your recovery phrase.

If you always use the same relayer from the same IP, that relayer can build a usage profile of you over time. If you rotate relayers or run your own, it cannot.

It leaks more than people expect, less than naive intuition suggests.

An on-chain observer can see that group X exists, roughly how many members it has, how often it is active, and when governance events occur. They cannot read message content (none is on chain), cannot tell which group member triggered an action when ZK proofs are used, and cannot tie an on-chain identity to a real-world person from the chain alone.

Combine the chain with relayer logs, and a patient adversary can run intersection attacks. We are honest about that on the threat model.

Your twelve BIP-39 words restore your identity, contacts, and key material on a fresh device. If you have not written them down, no one — not the maintainer, not a recovery service, not Apple, not Google — can give them back. That is by design.

Group history that lived only on your old device may be unrecoverable. Group state that lives on chain (rules, current membership) is restored along with your identity.

Honestly, in a group of three, sender anonymity is bounded by group size. ZK proofs prove “a member sent this” without saying which; in a tiny group, the search space is tiny.

The protection becomes meaningful as groups grow. For a small group of close friends, you should assume members can guess who said what from style and timing alone. For a larger working group or a public-facing group, the cryptographic anonymity matters.

They can read everything sent in the group while they are a member. They can screenshot. They can leak. They can probe sender anonymity within the group. None of that is solvable by any cryptosystem.

What they cannot do: impersonate another member, exceed the role granted by the group governance contract, or rewrite group history beyond what governance permits.

Today, a single maintainer, working in public on MIT-licensed code. There is no Foundation, no Series A, no advisory board. The maintainer’s name and account are visible on GitHub on every commit; the website just doesn’t put them up in lights. The about page is honest about this.

If a Foundation is formed later, it will be announced with jurisdiction, registration, and a real charter. Until then: solo, MIT, in public.

It is, just not in lights. Every commit on every Onym repo is signed by the maintainer’s GitHub account; you can find the name in 30 seconds. The website doesn’t put it on a banner because the project shouldn’t be about the person — the trust you extend should rest on the code, not the name.

Every layer is on GitHub. Every primitive is standard. The threat model is published. If any of those become inaccurate, fork the code and continue without us.

The maintainer cannot hand over what they do not have. There is no Onym-controlled account database, no message store, no recoverable social graph held centrally. A relayer operator can be compelled to log new connection metadata going forward, which is one reason transport is replaceable and you should run your own when it matters.

Group rules are immutable on Stellar. No legal process compels a Soroban contract to behave differently than its source code says.

This is a real risk for any project, including Onym. The mitigations: every layer is MIT-licensed, every layer is on GitHub, the cryptographic primitives are not novel, and the protocol is documented. Anyone capable of reading the code can fork it the day this page becomes inaccurate.

The on-chain Soroban contracts are immutable; existing groups continue to function regardless of who controls onym.app.

Stellar/Soroban gives us cheap, fast, deterministic smart contracts with a relayer-pays model that lets users transact without funded accounts. Ethereum is more expensive and a less natural fit for the relayer model. Bitcoin lacks the contract surface. Solana is fast but the deployment model is different. A private ledger would put one operator back in the trust path.

The choice is reversible. If the trade-offs change, we will say so.

No. The primitives in production today — BLS12-381, secp256k1, Ed25519, X25519 — 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.

If your threat model includes a record-now-decrypt-later adversary at nation-state scale, weigh that.

You have to trust some build, somewhere. The mitigation we offer is reproducible builds: every layer is open source, the source corresponds to the binary, and you can build the apps and the relayer from source yourself if you do not trust the published binaries.

Reproducible Apple App Store builds are an open problem we share with every iOS app. We will publish reproducibility status with each release as the tooling matures.

Not yet. The cryptographic primitives have decades of public scrutiny. The contract logic and the integration code do not, and will be audited when the project can fund it. Audit status will be published in the changelog when it changes.

Alpha builds for iOS and Android are available via the QA Dashboard. The architecture, contracts, and SDKs are on GitHub.

For correspondence, including from journalists and security researchers, write to lead@onym.app. Replies usually within a working day.

Email lead@onym.app with “security” in the subject. Disclosures that improve the threat model are the most useful disclosures there are.