The clever part is what a server can't see.
The architecture, in plain words. Where something is not live yet it is written in the future tense and labelled, because the alternative is the mistake this whole project is organised against.
Encrypting what you say is solved. We work on who, when, and how often.
Every serious messenger hides the contents of a message. What most of them still expose is the pattern around it. That pattern is the map of a life, and it is what a court order actually collects — not because anyone chose to collect it, but because it is what exists.
Avano is built so there is far less of it: less transmitted, less held, less that anyone can come and ask us for.
We do not invent our own cryptography. Message encryption is unmodified libsignal — the library Signal wrote and had audited. All the new work is at the layer above it: metadata, the network, and the way it feels to use. That division is deliberate and it is the single most important design decision in the product. Rolling your own cipher is how amateurs are identified; the interesting, unsolved problems are all in the layer nobody had done properly.
How you exist here without an account existing.
When you first open Avano it generates a recovery phrase and derives a cryptographic key pair from it, on the device. That key pair is your identity. It is never sent to us, and there is nowhere on our side that it would be stored if it were.
This has consequences worth spelling out, in both directions.
- There is no accounts table anywhere, so a legal order naming a user has no referent. This is not a policy of refusing to answer; there is nothing to answer with.
- Nothing about you exists in an outside database already. A phone number is an identifier that already sits in a carrier's records, a subscriber file, and every contact upload anyone ever made. Not having one removes an entire class of correlation before it starts.
- Nobody can look you up. There is no directory, no search, no discovery. Somebody reaches you only if you gave them a link.
- And we cannot help you if you lose it. There is no reset, no support recovery, no "prove it's you". That is the same property from the other side, and it is why nobody impersonating our support can ever ask you for anything useful.
Pairing: the one-time link
To talk to somebody, one of you creates a single-use invitation and gets it to the other by whatever channel you already trust. The invitation is spent on use. Both devices then hold a shared secret established at pairing, and each of you gets a private address for the other to reach you at — a different one for every contact, so two of your contacts can never discover they are both writing to the same person.
There is no QR scanning. The app requests no camera permission and contains no code scanner; if you have seen a code-like pattern in the interface, it is decorative and encodes nothing.
Two different layers, doing two different jobs.
These get conflated constantly, including by us in earlier drafts of this page, so they are separated here.
- libsignal, unmodified. The Double Ratchet, with a post-quantum key exchange at session setup and a continuous post-quantum ratchet afterwards.
- The setup mixes a classical elliptic-curve exchange and a quantum-resistant one, so an attacker has to break both to learn anything.
- The continuous part is the one that matters most and is the newest: fresh quantum-resistant key material is injected throughout the conversation, not only at the beginning. A single compromised moment does not open the rest of the session.
- This is not our work and we do not want it to be. It is the same code, at the same version, doing the same thing it does in Signal.
- Everything travels through a Tor client built into the app. Our relay is published only as an onion service.
- Tor's own encryption is classical. That means somebody recording traffic today could, with a future quantum computer, decrypt the transport — which address was dialled, which slots were collected, and when.
- Since that transport detail is exactly the metadata this product exists to protect, we do not rely on Tor alone. A second hybrid channel — classical and quantum-resistant together — is established inside the circuit and seals every frame.
- What remains outside our control: that somebody dialled our relay at a particular time. That is Tor's, and it is really a question of how many people are using the service.
The message layer is. The circuit layer that Tor provides is not, and no shipped change reaches backwards to anything already recorded. Both halves of that sentence are true and only saying the first one is the kind of overclaim we treat as a defect.
Sarah writes “running late.” Here is every hop.
- On Sarah's phone The text is sealed end-to-end for exactly one recipient, then padded — first to a fixed plaintext size, then into a single 4096-byte block. A two-word message and a long paragraph produce identical bytes. There is only ever one block size, on purpose: a second size class would let a relay tell "a conversation is starting" from "a conversation is continuing" by length alone.
- Into the circuit The block leaves through the embedded Tor client and is wrapped again in the hybrid wire channel, so the destination slot code and the routing details are sealed as well — not just the message body. The relay never sees Sarah's address.
- At the relay It lands in a slot as one opaque block. No account, no sender field, nothing on the disk. The relay can route it without ever being able to read it, and it does not know it came from Sarah — that information is not in the protocol. Exactly what the relay does see →
- To the recipient Their device collects from its own slots when the app is open, spread across eight separate connections, each on its own randomised schedule rather than all at once. It pulls the block and opens it. The plaintext exists only on the two phones.
- Afterwards If a disappearing timer is set, both copies are swept when it expires. The timer is a single setting that applies to every conversation — there is no per-chat timer, so one set from inside a chat is set everywhere. If it is off, the message stays on both phones until somebody deletes it. There is no third copy anywhere, and no backup.
What is stored, and how well.
Everything Avano keeps lives on your device and nowhere else. It is encrypted item by item, with a key held in the phone's hardware-backed key store. If you set a passphrase, the key becomes an entanglement of that hardware key and your passphrase, stretched with a deliberately slow, memory-hungry function — so extracting the hardware key gets an attacker nothing on its own.
Identifying fields are stored under blind indexes rather than in the clear: contact names, session recipients, message conversations, per-contact slot owners and group senders are all keyed opaque hashes, with the readable name sealed inside the value.
Three things that are still readable, and we are not going to bury them
- Some housekeeping keys carry contact names. Their values are sealed; the keys themselves are not. A seized device therefore still yields a list of who you have contacts with.
- A group identifier is stable and global, so two seized devices can be shown to have been in the same group.
- Whole-file database encryption is not in use — the sealing is per item — so the database's structure and indices are readable.
Until those are closed the accurate claim is: message bodies, identities and session state are sealed; the contact list is not.
Locking
The app locks when it leaves the foreground and after a short period without a touch. Locking tears the live account down so the sealing key is wiped from memory; unlocking re-derives it from your passphrase, supplied again. That this genuinely happens is checked by scanning memory for the key after a lock, with a control that finds it before — rather than by checking that a flag flipped, which a key-caching implementation would also satisfy.
The consequence of locking is the one people notice: a locked Avano cannot receive. It cannot even learn that mail is waiting. That is the design, and it is why there are no notifications.
Duress features — do not rely on these yet
There is a duress passphrase that wipes and opens an empty decoy, and a counter that wipes after repeated wrong attempts. Both are weaker than they should be today: each depends on a small side file that can be deleted to disable it, and the decoy is distinguishable from a genuinely fresh identity by its timestamps. A decoy that can be detected is worse than none, because it is detected while you are in the room. We are describing these as unfinished rather than as features.
Files, groups, and the things that give you away by their size.
Sending to a group posts one block to each member's address within a moment of the others. A relay that watches which addresses receive something, and when, can work out group membership over time without opening anything. This is a published weakness of this entire family of designs — it applies to Signal's sealed sender too — and the number of observations needed grows only slowly as a service gets larger, so growth does not dilute it. The defence is temporal and only part of it is built. The full picture →
Designed, wired, and not yet delivered.
Three things this page could easily describe in the present tense that are not true in the present tense. The roadmap has the complete list.
The two-relay split
The code is written so that no single relay sees both ends of a conversation. A second relay exists, run by a different company on a different network in a different country. The app does not yet dial it, so today both directions land on the same host — separate connections and separate circuits, which defeats one kind of correlation and not the other.
Rotating addresses
Each per-contact address is designed to rotate on a schedule, so no single code stays correlatable indefinitely. The mechanism is implemented and tested in the engine and nothing in the app calls it yet, so in practice your addresses are stable. We list it here rather than in the feature list for exactly that reason.
Cover traffic
Your phone sends at a steady rate whether or not you are writing, so an observer cannot read your volume. On by default, free, for everyone — because a privacy lane you have to pay for marks the people who paid. It costs about 750 MB a month, which is why the switch exists. It hides volume, never presence.
No architecture survives an owned phone.
If a state-grade exploit runs code on your device, it reads the plaintext after decryption — the same way it would read any messenger, or photograph a notebook. No protocol property survives a compromised endpoint and we will not pretend one does. We are, today, worse than Signal on this specific point: our interface is rendered by the system web view rather than written natively, which is a wider surface than theirs.
And we have not had an independent third-party security audit. libsignal — the cryptography we build on — is audited. Everything we built around it is not, and that is where all our distinctive claims live. Until an audit happens we will not imply an assurance we do not have.
That is why we say metadata-minimizing, never "untraceable". Read the threat model → · See which of these claims you can check →
Six words this page uses precisely.
- Metadata
- Everything about a message except the message: who sent it, who received it, when, how big it was, how often it happens. Encryption hides the contents. Metadata is what is left, and for most people at risk it is the part that matters.
- Blind queue
- A slot at the relay identified only by a random code, which anyone can deposit into and only the holder of the right key can empty. There is no owner recorded and no sender recorded. It is the core of the design.
- Onion service
- An address reachable only from inside the Tor network. A connection to one arrives without a source address, and an ordinary connection cannot reach it at all — a plain socket cannot even resolve the name.
- Post-quantum
- Cryptography designed to stay secure against a future quantum computer. It matters now because traffic recorded today can be stored and decrypted later, which is why "harvest now, decrypt later" is a real threat rather than a future one.
- Cover traffic
- Sending at a constant rate whether or not you have anything to say, so that the amount you send reveals nothing. Sometimes called a constant-rate lane. It hides volume, not presence.
- Forward secrecy
- The property that compromising a key today does not open yesterday's messages. Achieved by continuously replacing keys as a conversation proceeds — which is what a "ratchet" is.
Read the claims. Then check them.
Every architectural claim on this page is one you currently have to take our word for. That is itself a page.