Money and messages that are yours alone.

Mainstream messengers tie identity to a phone number and route messages through infrastructure that can read metadata and often content. Aphanite removes both dependencies. Identity is a self-custodied wallet address, so onboarding needs no carrier and no personal data. Message bodies are end-to-end encrypted on the sender's device, so the relay only ever forwards ciphertext it structurally cannot read. And every monetized feature is confined to a perimeter — premium handles, verified accounts, larger groups, encrypted backup, and a developer API — none of which requires decrypting a message.

The engineering rests on a clean separation of two keys. The wallet key proves identity: it signs the Sign-In With Ethereum login and a one-line device-key authorization, and it never performs encryption and never spends. A per-device X25519 messaging key, generated in the browser and authorized by that wallet signature, does the actual encryption. Direct messages run the Signal protocols — X3DH then the Double Ratchet — for forward secrecy and post-compromise security; groups and the API use a per-recipient-device sealed box (ephemeral X25519 → HKDF-SHA-256 → AES-256-GCM), so multi-device delivery just works.

The component that could betray users is the directory that maps a handle to a key. Aphanite writes every handle→key and device authorization into an append-only SHA-256 Merkle transparency log. A client can request an inclusion proof and check a binding against the published root, and any key change appears as a new, visible leaf. We are candid in §12 about what this log does not yet do — roots are not signed, there is no gossip or consistency-proof protocol, and while established direct conversations are now routed by unlinkable mailbox tags, first contact and groups remain identity-addressed — because a privacy audience will check, and overclaiming is how privacy products lose trust.

The reference server persists state through a single append-structured store and is deliberately simple; it is the directory, the consent ledger, and the relay queue, but it is never a decryption oracle. The cryptography is built entirely on audited primitives from the @noble libraries (X25519, SHA-256, HKDF, AES-GCM, Argon2id) with siwe for login and jose for sessions — Aphanite composes standard building blocks rather than inventing new ones.

Two keys, two jobs. Every user is identified by a self-custodied wallet address over secp256k1. But wallet keys are built for signing transactions — they rotate poorly and live in hardware you don't want in the message hot path — so Aphanite never encrypts with them. Instead, each device generates its own X25519 messaging keypair in the browser and stores it locally. The wallet's only cryptographic role in the protocol is to authorize that device key.

Device authorization. To bind a device key to the address, the wallet signs a short, human-readable authorization message — the user sees exactly what they approve (legacy string retained for signature continuity):

sealed Device Authorization
Address: 0x…
Device messaging key: <x25519-pubkey>
This key may encrypt and decrypt your sealed messages on this device.
It does not authorize spending.

The signature is stored with the device record on the server and the binding is written to the transparency log (§6). Because each device is an independently authorized key, Aphanite supports multiple devices per account and per-device revocation without ever moving the wallet key: a sender simply seals a copy of each message to every one of a recipient's active device keys.

Verification & revocation. Users can compare a safety number— derived by hashing both parties' device keys — exactly as in Signal, and can run an in-chat live verification in which a contact signs a random challenge with their wallet to prove the address behind the conversation. Revoking a device marks it inactive and appends a device-revoke entry to the transparency log, so the change is publicly visible to anyone auditing that address.

The flow is a standard challenge–response. The client requests a one-time nonce (a random 128-bit value that expires in ten minutes and can be used once). The wallet signs a human-readable SIWE message embedding that nonce and the site's domain. The server verifies the signature, confirms the nonce is unused and unexpired, marks it burned, and issues a session as a signed, HttpOnly cookie valid for two weeks. Sessions are individually revocable, and users can see and end active sessions from settings.

One wallet can also link additional wallets to a single identity: a linked wallet signs a binding statement, and thereafter signing in with it resolves to the same primary account — useful for users who hold multiple addresses but want one inbox.

A handle is a short human-readable name (three to twenty characters, a–z 0–9 _), unique and one per address. Claiming a handle, and every device authorization or revocation, appends a leaf to a single append-only SHA-256 Merkle tree. After each append the tree's root is recomputed and published with its size and timestamp; the public transparency endpoint returns the current root, recent entries, and — for any handle or address — an inclusion proof that the binding is present under that root.

• Auditable bindings. A client can fetch and verify an inclusion proof before trusting a key, checking that the handle→key binding it was served is actually in the published tree.
• Visible key changes. A new device or a revocation is a new leaf, so a contact's key rotation is observable — the basis for a "safety number changed" warning.
• Free users included. The device-key registry is independent of handles, so even users who never claim a handle have an authorized, logged key that others can encrypt to.

A sender's first message to someone new does not land in their inbox; it becomes a requestcarrying an encrypted intro. When the recipient accepts, both parties are added to each other's allowlist and messages flow normally thereafter. All of this consent state gates delivery, never content, so it is fine for the server to hold — knowing that A may reach B reveals nothing about what they say.

Spam marks and blocks. On top of consent, recipients hold two unilateral controls. Marking a sender as spam silently stops delivery from that sender — the sender is not notified, there is no path to buy or work around the mark, and only the recipient can lift it. A hard block stops delivery entirely. Both are delivery-layer state: they gate routing, never content.

Direct messages — the Signal Double Ratchet (dr-v1). One-to-one conversations use the same protocols behind Signal and WhatsApp. The first message performs an X3DHkey agreement against the recipient's published prekeys, and the conversation then runs the Double Ratchet: a fresh key is derived for every single message and thrown away after use, and new key material is continuously mixed in as the two sides exchange. This gives two strong properties — forward secrecy (stealing today's keys can't unlock yesterday's messages) and post-compromise security (a conversation automatically heals itself after a compromise). Sessions live encrypted on your device.

Groups & the API — sealed boxes (box-v1). Group messages and the developer API use a per-message sealed box: the client generates a throwaway ephemeral X25519 keypair, agrees a shared secret with each recipient device key, derives a 256-bit key with HKDF-SHA-256, and encrypts with AES-256-GCM. A group message is sealed once per member device, so the content guarantee is identical to a 1:1 chat. Discarding the ephemeral key gives sender-side forward secrecy; because there is no ratchet here, groups don't yet self-heal after a device-key compromise the way direct messages do (see §12).

The blind relay. Sealed envelopes are posted to a store-and-forward relay that holds them for offline recipients. Delivery is confirmed by the client: the relay hands over pending envelopes without deleting them, and only marks them delivered once the client acknowledges the specific messages it actually decrypted — so a session with a stale key can never destroy mail meant for another device. Delivered envelopes are pruned after seven days and everything is pruned after thirty, so the relay is a short-lived buffer, not an archive. The server also runs a structural proof-of-sealing check, rejecting any envelope whose fields are not shaped like real sealed-box output — catching a client that tries to send plaintext by mistake, without the server ever reading what is sealed.

Rich messages over the same channel. Delete-for-everyone, disappearing (burn-on-timer) messages, group fan-out, and live identity verification all ride inside the same encrypted channel as structured payloads, so the server sees only ciphertext for these control actions too.

Unlinkable mailbox tags & sealed sender. Once a direct conversation is established, the two clients exchange a per-conversation secret via an encrypted control message inside the channel, and delivery moves off identity addressing. Each side derives a rotating mailbox tag as HMAC-SHA256(per-conversation key, epoch day index), rotating daily; envelopes then carry only {tag, ciphertext}, submitted and fetched over unauthenticated, sessionless calls that carry no session identity. A recipient pulls and acknowledges mail by naming the tag; per-device routing uses HMAC-derived device hints rather than device keys. The relay therefore stores ciphertext under an opaque label — no sender, no recipient, no device identity — and cannot see who is talking to whom in an established conversation. Plaintext lengths are hidden by padding messages to fixed-size buckets, and clients poll on a jittered schedule to blunt timing correlation.

A group stores only its membership and metadata — name, visibility, creator, an optional avatar, and an optional password hash. To send to a group, the client seals the message pairwise to every member device, tagged with the group's identity so the recipient files it correctly. This keeps the content guarantee identical to one-to-one chat, at the cost of sending one sealed copy per recipient device.

Groups can be public or invite-only, and public groups may be gated by a join password. Free accounts can host groups up to eight members; the larger-groups entitlement raises the creator's cap to sixty-four. Official, verified system groups (such as a curated news channel) carry a checkmark and float to the top of discovery. Group creators can also mint scoped bot tokens so automated services can post into a group through the developer API.

A backup encrypts the device's full Aphanite state — messages, settings, contacts, and the device keypair itself — under a key derived from a user passphrase with Argon2id, the memory-hard password KDF, and then AES-256-GCM. Only the resulting opaque blob is uploaded; the server holds bytes it cannot decrypt, and without the passphrase the backup is unrecoverable. Restoring on a fresh browser re-creates the exact messaging identity and can immediately decrypt history. Backups can run automatically on a schedule or be exported as a file.

Multi-device follows from the same design: each new device generates its own wallet-authorized key, and either an existing device or an encrypted backup provisions its history. No plaintext ever transits the server.

Entitlements are recorded per address by an on-chain payment, then checked at feature boundaries. The developer API exposes a versioned /api/v1 surface authenticated by sk_live_ Bearer keys (stored only as salted hashes, shown once at creation, rate-limited, and revocable). It lets builders introspect their own identity, resolve public handles and device keys, and submit or pull already-sealed envelopes — the same guarantee sold to developers, since the API never sees plaintext. A published OpenAPI description documents the endpoints for directory lookups, key resolution, envelopes, and groups.

Consumer chat is free forever: it is the top of the funnel and the source of reputation and network effects. The business is the perimeter around it.

About this document. Aphanite — v1 Architecture Whitepaper, July 2026. This edition describes the architecture as implemented in the current codebase. It is a technical and strategic overview, not a security audit; the cryptographic and directory constructions should be independently reviewed before high-risk use.