The protocol, stated with its limits.

QERYX is a phone-number-free, end-to-end encrypted messenger whose 1:1 sessions are established by an asynchronous signed-prekey handshake combining an ephemeral X25519 exchange with an ML-KEM-1024 encapsulation to the recipient's published keys — and, unlike every surveyed deployed messenger, the handshake is authenticated post-quantum: identities and prekeys are signed with ML-DSA-87, and a signature that does not verify against the transparency-anchored identity refuses the session. A peer that has never published a signed bundle is accepted once, binding-unverified. Message keys advance on a one-way HKDF-SHA-512 chain, giving per-message forward secrecy above a harvest-now-decrypt-later-resistant root. For messages the relay is a delivery spool: a delivered message is hard-deleted within minutes of the recipient's own acknowledgment; undelivered ciphertext, a group message sealed to each member, and a message read with Stealth Mode on or read receipts off within 30 days; and the scheduled purges — delivered rows at the grace window, the rest at the horizon — each write an ML-DSA-87-signed destruction receipt carrying the hashed message identifier and its received, delivered and destroyed timestamps, sealed hourly into a Merkle batch an account holder will be able to walk at /fsor/audit — receipt, leaf, inclusion proof, signed root. A photo, video or file is stored apart, outside those purges, for up to 45 days after upload. Deletion is a first-class protocol object — a signed, replay-protected intent verified on every device against a key-transparency-pinned identity, with an irreversible local ledger and a residue-checked relay purge. Groups distribute per-sender keys under ML-KEM-1024 wraps with ML-DSA-87 signatures, arbitrated by a PQ-signed membership tree; calls negotiate fresh per-call hybrid keys with post-quantum caller authentication, and the video plane rebases its media root under ML-KEM-1024 every 3,000 frames. This overview states, for each mechanism, what executes in revision 1 and what activates in revision 2.

The protocol is engineered against five adversaries: a recording adversary harvesting ciphertext today to decrypt with a future quantum computer; a compromised or coerced relay, including its database, logs and backups; a seized or lost device; a malicious group member; and the metadata observer for whom who-talks-to-whom is the product. Confidentiality of a session holds if either X25519 or ML-KEM-1024 holds; authentication holds against a quantum forger because the signatures themselves are post-quantum.

Out of scope, and stated so: a fully compromised endpoint reading plaintext on-screen; network-edge IP visibility; and denial of service by the operator, who can always refuse to carry traffic — the design goal is that carrying it teaches the operator as little as the lifetimes table below permits.

A device generates a 256-bit secret — the Serpent ID — and derives the public Profile ID from it by a truncated one-way SHA-256; the 256-bit factor that authenticates the account is a separate device-held secret the relay only ever sees as an Argon2id hash. Registration sends the Profile ID and that hardened verifier; the relay stores no phone number, no e-mail address and no display name. The ML-DSA-87 identity key is the anchor of trust: its hash binds contact names, conversation keys and deletion authority, and survives a Profile-ID rotation.

Every peer key is pinned through the Key Transparency Service: an append-only SHA-384 log whose roots are signed with ML-DSA-87. Clients verify an inclusion proof for the exact leaf that binds the profile, the identity key and the key-bundle epoch, against an operator key pinned at build time; sequence rewinds are refused; devices gossip roots to detect a split view. The log publishes its own trust posture at GET /kts/trust-phase — it answers operator-only, with external witness co-signatures as phase 2. Identity keys rotate on a 30-day schedule; each rotation is signed by the prior key, chained in the log, and verified by every peer before re-pinning.

A session begins from the recipient's published key bundle: an ML-DSA-87 identity key, an ML-KEM-1024 encapsulation key and an X25519 key, bound together by an ML-DSA-87 bundle signature that the fetching peer verifies against the transparency log — the relay stores it and cannot forge it. The initiator performs an ephemeral X25519 exchange and an ML-KEM-1024 encapsulation; the two shared secrets are concatenated into the key schedule, and the derivation salt commits to the recipient's exact bundle and to both transmitted values — the ephemeral key and the KEM ciphertext — so no component can be substituted in flight. The first message is signed with ML-DSA-87 over the ephemeral material, fail-closed, and a device-attestation digest rides inside the authenticated data: the relay verifies the platform attestation chain to its pinned root at key publication, and the first message is bound to that fact — an advisory peer-facing badge, not a gate.

The property to hold onto: the deployed post-quantum messaging designs and the MLS ciphersuites in deployment all establish keys post-quantum but authenticate them with elliptic-curve signatures — a future quantum forger attacks their identity layer, not their encryption. QERYX signs the handshake with FIPS 204 signatures. Stated limits: the signed first message is deliberately non-repudiable; one-time prekeys are implemented but not yet serving, so first-message forward secrecy is bounded by bundle-key rotation until they ship.

The Q-Ratchet is a four-chain design over one bootstrap secret: a per-message HKDF-SHA-512 symmetric chain; an ML-KEM-1024 epoch chain with an ownership-alternating trigger and redundant boundary frames; an X25519 chain folded at epoch reseed; and a committed re-keying chain that stamps an 8-byte synchronization commitment into the header every 5 messages.

Executing in revision 1: the symmetric chain produces every message key — delivered messages are unrecoverable from a later compromise — with an out-of-order cache, the full header bound as associated data, replay refusal that commits only after authentication succeeds, and the sync commitment. Session roots carry ML-KEM-1024 harvest-now-decrypt-later resistance from the handshake, and sessions re-establish on prekey change, which is the recovery path in revision 1 after a device compromise.

Activating in revision 2: the in-session ML-KEM epoch chain (message-count and wall-clock triggers), the X25519 fold at each epoch reseed — restoring the "secure if either holds" argument continuously rather than at establishment — and peer-agreed entropy re-injection on the fourth chain. We publish this distinction because a protocol document that does not separate design from execution has not earned a reader's trust.

"Delivery" means one thing: the receiving device's own signed-for acknowledgment. A push notification retires nothing. From that acknowledgment, the ciphertext row enters a published, timer-driven death: a 10-minute grace, a sweep every 15 minutes, a hard SQL DELETE — and before every deletion, an ML-DSA-87-signed destruction receipt carrying the hashed message identifier and its received / delivered / destroyed timestamps, sealed hourly into a Merkle batch an account holder will be able to walk at /fsor/audit — receipt, leaf, inclusion proof, signed root. A group message, sealed to each member by default, and a message read with Stealth Mode on or read receipts off take the retire lane instead and are deleted at the offline horizon. A photo, video, file or group voice note is a separate upload, not deleted with its message row: the relay deletes it at its own expiry, up to 45 days after upload, unless its sender deletes it sooner.

Honesty the code itself carries: the database engine does not zero reclaimed pages, and write-ahead logs and backups sit outside the application's reach — which is why the claim is erasure with signed receipts and stated residue, never "mathematically gone". Sealed sender on the default text lane keeps the sender off the stored row and out of the logs; a blind-token submission lane beside it is built to be unlinkable to the account at send time, and will be described as such once a two-device capture on the relay shows it carrying traffic. A privacy claim that will not name its numbers is a slogan; the table above is the difference.

A delete is an ML-DSA-87-signed, replay-protected intent, verified on every receiving device against the transparency-pinned identity of the conversation — authority is established by cryptographic commitment, never by looking up who asked. Locally it drives a monotonic ledger that can never un-delete, a multi-step destruction of transcript, media, search index and keys, and a purge registry that survives re-pairing: the same two people can start again on a fresh surface, while the pre-delete corpus can never be routed, re-served or rendered — a clean-slate boundary; the purge registry can never be lifted — a re-pair with the same person opens a fresh surface, it never reopens the old one. For a one-to-one thread, authority is a cryptographic commitment — the conversation the frame may destroy is derived from the exact key the signature verified under, so naming a third party's thread would take a preimage of that party's fingerprint and a signature under it. A room is different: there the device also checks its own copy of the roster and the admin set. On the relay, the purge deletes, in one transaction, the rows it can tie to the conversation, rolls back if a row it checks survives, and concludes with a signed destruction proof. A one-to-one message, sealed by default, names neither its sender nor its conversation, so the purge does not reach it: it leaves on its own clock, as any message does, and each photo or file keeps its own expiry.

When a frame cannot be decrypted, Q-Echo asks the original sender to re-seal it under a fresh key through a relay lane that writes nothing to disk — delivery truth instead of silent loss — and each device keeps an ML-DSA-87-signed Merkle audit chain of every revival. The cross-device comparison of those chains is roadmap; the chains themselves are built.

Groups. Each sender runs its own key chain; the chain key is distributed to every member wrapped under ML-KEM-1024 to that member's transparency-verified bundle key and signed with the sender's ML-DSA-87 identity over the conversation, sender, recipient, epoch and payload — receivers refuse unsigned or mis-bound installs. Sender keys rotate every 100 of a sender's messages and on every verified removal. Membership itself is arbitrated by a separate authority: a TreeKEM-inspired tree whose leaves are hybrid X25519 + ML-KEM-1024 keypairs and whose commits are ML-DSA-87-signed and verified against pinned committer identities — widening the roster without a verified commit is refused. Stated limits: group frames do not yet carry per-message authorship signatures or recipient-bound associated data (both are implemented in the core library and staged), and the relay's escrow of wrapped keys is bounded for every superseded epoch (swept on a 15-minute loop past the sender-key horizon) while the current epoch's row stays until membership changes.

Calls. Every call performs a fresh hybrid X25519 + ML-KEM-1024 handshake under a per-call ML-DSA-87 signing key, with a five-minute freshness window and nonce replay cache. The caller additionally signs the call — callee and relay verify it against the pinned identity — and both ends confirm the derived master key with an authenticated tag; the far end's identity is verified once, in person, through the Entangled pairing, not on each call. Voice media runs under per-packet AEAD keys derived on a 10 ms frame clock, with a symmetric chain ratchet every 200 packets; its ML-KEM-1024 half is established once per call, and the in-call KEM rebase is a protocol-revision item. Video binds its 13 header bytes as associated data under a 1,024-frame replay window and rebases its root under ML-KEM-1024 every 3,000 frames. Stated plainly: this is application-layer AEAD keyed by a post-quantum-authenticated handshake — not DTLS-SRTP — and voice packet headers gain associated-data binding on the roadmap.

Every primitive is gated at process start by known-answer self-tests on both the device and the relay — a failing test refuses to run — and on iOS 26 and later a second implementation cross-checks ML-KEM-1024 and ML-DSA-87 against crypto-core: an ML-KEM divergence halts the launch, and a platform-framing divergence on ML-DSA is logged without halting, because that lane sits above the floor rather than being it. Every HKDF and signature context uses a registered, uniqueness-tested domain separator. The modules are not CMVP-validated, and this document says so rather than implying otherwise. In research: Q-Entangle-Bell, a classical CHSH-form co-possession ceremony folded above the hybrid floor — designed hardware binding, not active, and never part of a key-secrecy claim. Entropy: keys are generated from the OS CSPRNG; server-relayed, health-tested entropy is conditioned in as defense in depth and never relied on alone.

A protocol document that lists no limits has not been reviewed hard enough. Each row above is enforced across this site, the application and the specification.

Verify it on your own device, once it is in your hands: the destruction audit trees at /fsor/audit; the transparency log's own trust phase at GET /kts/trust-phase; and the in-app self-tests — AEAD forensics, tamper drills and the Q-Echo audit walk — run in Settings against your session. The chapter-by-chapter specification behind this overview renders at /research with per-paper versioning; a signed PDF edition follows the release-signing ceremony — until it exists there is no download link, on purpose.

QEP-1 is the QERYX Entanglement Protocol: the entanglement ceremony and the Bell bond as one thing, written for the auditor who verifies from artefacts alone. It is a different construction from Q-Entangle-Bell in section 08 — that one is a classical ritual over two seeds; this one measures entangled pairs on a processor — and it is not in the app yet. It exists in the source tree; the app carries it once the relay and the app that fold it are ready. Every sentence below describes the source. The full document is docs/protocol/QEP-1.md; the auditor's page is /trust/qep.

The ceremony. Two identities pinned in the transparency log exchange three frames. Every frame names its recipient, carries a fresh 16-byte nonce and an ML-DSA-87 signature under a ceremony-specific context, and is verified under the key the log verify pinned — never under a key the relay served. A witness derived over the two identity keys, the conversation and the nonce is compared by machine on both phones; no digit is rendered. The accept travels sealed under the responder's session, so the initiator's open of it is the first key confirmation, and ENTANGLED lights only then.

The bond. Each phone draws a string of measurement settings from its own randomness and publishes a SHA3-256 commitment to it before any pair is measured; a node that learned the settings first could fabricate any Bell value, so it never learns them first. The mint measures Bell pairs on a cloud processor in those settings, seals each phone's outcomes to that phone's own X25519 + ML-KEM-1024 bundle key, discards its copy, and publishes a signed receipt: the processor's name, the aggregate S with its standard error, the pair counts, the mint's build hash and a pulse from the public Bell beacon. The phones reveal their settings to each other over the sealed channel, keep the matched pairs, estimate the error on a one-in-ten sample, and run the CHSH test on the mismatched pairs: at least 800 pairs, S at or above 2.2, and S minus three standard errors above the classical bound of 2, or the bond fails and the chat is unchanged. The reconciled bits are hashed by a Toeplitz extractor to a 256-bit block; both phones exchange the block's commitment and fold the block beside the post-quantum root — both or neither. Both identities sign a certificate over the round, the block commitment and the handshake; the log publishes one per pair, records a leaf-aware witness signature, and asks a public RFC 3161 timestamp authority QERYX does not operate for a token over the leaf hash; each phone reads the other phone's copy back and compares. Two blind tokens, one from each side, open one round, and the ledger prints the measured cost per bond every round.

The honest sentence, per rung. At the first rung, with one processor as a trusted node: "key material for this chat came from measuring entangled pairs in bases your two phones chose; the vendor and our mint saw the outcomes." With two processors and the blocks combined: "no single machine ever held this chat's block." With a round every epoch, the possession challenge and the witnessed erasure: "this chat's key is re-measured every epoch; a copied identity key alone cannot continue it." With the phone's own random silicon choosing the settings: "your phone's own quantum randomness chose the bases." With two processors holding the two halves over a photonic link: "the two halves were never in one machine." With the dock: "your device measured its own half." Each rung replaces one part; none rewrites the protocol. Only the first is built.

Verify it. The reference implementation exists twice, in Rust and in Swift, bound by one vector file of seven cases whose blocks reproduce from either side; the round receipts and the mint's key and build hash are published on unauthenticated endpoints; a conformance binary that replays the vectors and every published receipt is specified and being built. What no artefact reveals: an outcome, a block, or a key.