01 / 06
LiveOne-on-one.
A two-party encrypted thread. No admins, no votes — just two devices and their keys.
Open · Anonymous · Onchain
No company in the loop. Identity, keys, and history stay on your device. End-to-end encrypted, with an honest threat model.
The product
A binary on hardware you don't own, run by a company you have to trust — its owners, its admins, and whoever can serve them a warrant. Their privacy ends where their org chart begins.
Group membership and governance live on Stellar. Anyone can audit the rules. No one can override them. The contract is the only shared state — and it's public by design.
Identity, keys, contacts, and message history are generated locally and stay on device. Nothing is ever synced to a cloud Onym controls. What does cross the network — encrypted message blobs, signed Stellar transactions — is named in the threat model.
Twelve words.
Write these down. Never share them.
Choose governance.
Set the rules for who can admit, remove, post.
Sovereign identity
Generated on this device. Stored only on device. Never synced to the cloud. Never sent anywhere. These twelve words restore your Nostr, Stellar, and BLS keys on any device — and they are the only key to your chats.
Tap an identity to open it. Each identity has its own keys, chats, and recovery phrase.
YOUR IDENTITIES
Only the active identity's chats are visible. Switch between identities to see different inboxes.
The relayer, plainly
Onym uses a relayer: a small service that submits your signed Stellar transactions and pays the on-chain fees so you never need a funded account. It is a server. It is not a server with kill-switch authority over your account, your conversations, or your group’s rules. The difference matters.
A full accounting of what every party sees lives in the threat model. Short version, drawn:
* IP unless you bring your own privacy network. Run your own relayer or use several — the protocol is the same. Contract address tells the relayer the group’s governance flavor; cleartext membership lives inside the contract as commitments. The diagram shows the common case (in-group state changes via update_commitment); create_group additionally carries a Soroban auth entry signed by the founder, the only call where a user-bound signature touches the chain.
No one — not even Onym
Anonymous identities · No phone numbers · No address book.
Governance models
Three live today; two on the roadmap. Each is a separate Soroban contract suite — the family shares one client-side call shape.
01 / 06
LiveA two-party encrypted thread. No admins, no votes — just two devices and their keys.
02 / 06
LiveA single founder admits and removes. Honest about who holds the keys.
03 / 06
LiveAnyone in can invite anyone. Anyone can leave. The group is what its members make it.
04 / 06
PlannedA majority of members admits and removes. Every change is a signed, on-chain vote.
05 / 06
PlannedA small council of admins. Threshold signatures decide who's in and who's out.
06 / 06
Bring your ownNeed a rule set we don’t ship? The protocol is governance-agnostic — propose a new flavor, or fork the contracts and define your own.
Cryptographic primitives
Onym is built from primitives that have been deployed, attacked, and studied by cryptographers for decades. No new crypto.
Keystone · the contract on top of these bricks
sep-anarchy
Seven primitives, one contract, any current member admits. The simplest of five policy contracts, with the full brick-by-brick soundness chain.
Membership
Merkle tree
32-byte root commits to the full set.
Group proofs
BLS12-381
Pairing-friendly curve for aggregate signatures.
Zero-knowledge
PLONK
Universal SNARK for membership proofs.
Hashing
Poseidon
SNARK-friendly hash inside the circuit.
NIZK transform
Fiat-Shamir
Interactive proof → one signed transaction.
Polynomial commit
KZG
48-byte commitment, one pairing to verify.
Open source · MIT
Apps, contracts, relayer — every layer is MIT-licensed. Clone the source, audit the math, build reproducible binaries yourself. Onym never has to be in the path.