AVANOAvano
Developers

Build on a network that cannot see your users.

A contact on Avano can be a program. The same engine the phones run drives from a command line with no screen, a bot asks with cards and reads taps, an account proves itself to your service with a statement your code verifies from the bytes, and the protocol under all of it is specified and pinned by vectors computed from the shipping code. Nothing here needs an account with us, because there are none.

01 — Headless

The engine from a command line: open, invite, accept, send, receive, follow, take a seat.

The headless client is the phones' engine behind a command line: it opens an account from keys in a file, makes and accepts invitation links, sends and receives, follows a channel, posts to one, takes a seat on a company's relay, and runs as a bot that answers every message or hands each one to a command of yours. It reaches the network over Tor like a phone, or over a plain connection to a relay on the same machine for development. A bot is a contact whose other end is that program, and pairing already makes that possible without any directory.

The headless client

In the published source, built from it; an echo bot and an external-command bot included.

Built

02 — Cards

A card is text in a shape. The app draws it; your code never runs on the phone.

A card is a title, lines, up to twelve fields and up to eight buttons, written as text in a fixed shape the app recognises, the way it recognises a poll. The headless client assembles one from its arguments; an older phone shows the words. A button does one of five things: sends one message back to you with a payload you chose, readable by the person who tapped; opens a link through the phone's own dialog; opens the pairing or Follow sheet with a link in its field, which does nothing until the person acts; or copies text. Your code describes; the app draws, with its own renderer, from data. Mini-apps that ship their own code are a separate decision, written down and not built.

Cards

On the page both apps share and in the headless client; the shape held equal on both sides by a guard.

Built

03 — Identity

"Prove this account is yours", verified from the bytes, with nothing issued by anybody.

An Avano identity is a post-quantum key pair derived from the person's own words, issued by nobody. Your service shows a challenge, its own name and a nonce; the person's phone signs a statement for exactly that audience and nonce, carrying both public keys; your code verifies it with a small library and asks no server. The statement cannot be replayed to another audience, nor to you twice if you keep your nonces, nor from the past. A verifier that has seen the person before pins the post-quantum half and refuses a swapped one. What you learn is an address and a proof; what you do with them is your own account system, in which Avano holds nothing.

That is the first of three doors, and the design of the other two is written. Find and ask: a program holding an email its own user gave it may ask the registry what a phone asks, a blinded question paid with a token, and may propose a pairing that the person's phone puts to her; it learns whether handles it already holds are registered, at one token each, and nothing about any other. Sign in: a person signs in to your product with a key derived from her own words for your site alone, so you get a name that is stable for you and useless to anyone else, she comes back as the same person, and no server of ours is in the exchange at all. No door is a gateway: there is no HTTP endpoint, no API key and no account with the company, because a gateway that spoke on a program's behalf would see handles pass through it.

Identity attestation

The library, the vector, the command-line verifier, and the row on the person's own Shield screen.

Built
Sign in with Avano

A person signs in to your site with a key derived from her words for your site alone: the statement carries that key, your name and your nonce, and no byte of her account. The library, the vector, the command-line verifier and the row on her phone; and your page may show the challenge as an avano:signin/… link, which opens the app on that row with the challenge filled, so she reads your name and taps, and pastes nothing.

Built
Find and ask

The headless client speaks the phone's own discovery: register a handle after finishing the code the verifier sent, ask the registry about handles the program already holds (one token each, a match and nothing else), propose a pairing from the packet only that handle opens, and on the other side see who asked and answer, naming them. Run end to end on a box against the registry built from the same tree; the registry is deployed nowhere yet, and a program that pairs is an account, so there is no library apart from the client.

Built

04 — The protocol

Specified construction by construction, pinned by sixteen vectors from the shipping code.

Every construction Avano adds around its message layer is written out: the exact bytes, the inputs to every derivation in order, what each party checks and in what order, what is refused, and the adversary it is for. Sixteen known-answer vectors are computed by the very crates that ship each construction and held equal to the published files by a test, so a second implementation is checked byte for byte before it talks to anything. The protocol page is the map.


05 — The companion

A program that answers every message, for a store reviewer or for your first test.

The review companion is a headless account that answers every message with a fixed sentence, built for the store reviewer who needs a second party to talk to and useful to anyone testing an integration. It ran for the first time on 20 October 2026: a phone paired with it over a plain connection to a relay built from the source, wrote, and read its answer end to end.


06 — Paying

A bot pays like a phone: in tokens it mints, with no account.

When a relay meters, a bot buys its blocks the way a phone does, one blind token per block, minted by itself. Developer tiers on that rail, a bot that pays more to send more and nothing that names the developer, are built on the relay's side: a credential of a level, shown once per batch, buys blind tokens on the same issuer a solved one comes from, so a spend does not say it was bought. The console mints one, the headless client holds one, and its wallet buys its batches with it before it solves, falling back to work when a relay refuses and saying so once. Every level is zero until the prices are decided, so a credential buys nothing today. Today our relay does not meter, and a bot costs its author nothing but a machine.

What a tier is, in the design: a blind credential for a month, sold by the company, shown to a relay a few times a month to mint tokens without the proof of work a free account solves for. The company sees a sale and never which bot; the relay sees a credential's volume and never a person. What a tier will never buy, written down so it is not asked for twice: a badge or a place in a list of bots, delivery ahead of anyone else, bigger blocks, the right to message before consent, or anything about who read a post.