Every question, answered.

A post-quantum encrypted messenger and the ecosystem around it. Every conversation is sealed end-to-end: a hybrid ML-KEM-1024 + X25519 key agreement, ChaCha20-Poly1305 (RFC 8439) authenticated encryption, ML-DSA-87 identity signatures. The server is a carrier — it moves ciphertext it cannot read.

We carry the message. We hold nothing.

Κῆρυξ — kêrux — is ancient Greek for herald: the messenger whose word was inviolable by divine law. Intercepting a herald was sacrilege. QERYX is Q + Kéryx, the post-quantum stamp on the herald. The word survives in kerygma — the proclamation of truth.

Entangled describes what the protocol does. The four-chain Q-Ratchet advances a session secret that exists on both devices at once and is mathematically inseparable between them — a copy of one side without the other is dead bytes.

We do not claim literal quantum-mechanical entanglement. The primitive is named, and the claim stops where the code stops.

The protocol overview, the research papers, and the evaluation summaries are published here, and the transparency log will answer without an account — so you never have to take our word for it. The source and its audits publish with the open-source schedule. Start at About and the Trust Center.

On our own stack — MixcoatlDB, GlyconCache, QSFS are our names for a database, cache and object store we will run ourselves and their hardening, not new engines — under crypto-core, our own cryptographic library, on our own hardware in the EU, under EU jurisdiction. Infrastructure details belong to the Trust Center.

Yes. End-to-end encryption is a property of both ends: the hybrid ML-KEM-1024 + X25519 handshake runs between two QERYX devices, and the keys exist nowhere else. There is no SMS bridge and no gateway into other networks — a downgraded lane would become the lane an adversary picks every time.

Bringing someone in will take one step: sharing your public Profile ID. The first sealed message is the moment the conversation exists.

One account per person, one device per identity, and every conversation runs the same hybrid ML-KEM-1024 + X25519 handshake. Once QERYX arrives, you will share Profile IDs and open a group, and names, subjects, and every word travel sealed end-to-end.

A hybrid handshake: ML-KEM-1024 (FIPS 203) and X25519 together, so reading a session requires breaking both. Message keys ratchet forward with Q-Ratchet — one fresh key per message — derived through HKDF-SHA-512. Content is sealed with ChaCha20-Poly1305 (RFC 8439). Identities are signed with ML-DSA-87 (FIPS 204).

ML-KEM-1024 is a lattice-based key encapsulation standardized in FIPS 203 at Category V, chosen because traffic recorded today can be stored and decrypted by a future quantum computer. The classical X25519 half stays in the handshake so the hybrid never rests on a single assumption.

For recorded traffic, they already do: harvest-now-decrypt-later is a present-tense collection problem, and the CNSA 2.0 national-security gate lands 2027-01-01. The hybrid ML-KEM-1024 floor answers the deadline, not a mood.

A session key can additionally be bound to a CHSH-verified, Tsirelson-window-validated Bell-game transcript both peers seed and any auditor can verify — after both peers complete the Entanglement Ceremony. The operator-signed quantum-processor lane is designed and not active on any deployment. Bell-binding sits above the hybrid floor, never below it: breaking a session requires breaking both X25519 and ML-KEM-1024.

CNSA 2.0 — asymmetric core conformant (ML-KEM-1024 + ML-DSA-87 at Category V; SHA-512 at or above the hash floor). The AEAD is ChaCha20-Poly1305 (RFC 8439), a documented deviation; the AES-256-GCM NSS suite is implemented and reserved as suite 0x0002. Pre-evaluation checklist (internal self-assessment against the NIAP Common Criteria bar, latest pass 2026-06): 0 algorithm-layer non-conformances, 5 documented deviations; no accredited-laboratory evaluation has begun.

CNSA 2.0 disallows QKD for national security systems. QERYX's quantum work folds a co-possession witness into a KDF and never replaces the classical floor.

Constant-time performance on every device, with or without AES hardware, and a smaller side-channel surface. The deviation is documented, not hidden — the CNSA statement above carries it verbatim, and the AES-256-GCM suite is implemented and reserved as suite 0x0002.

Algorithm-conformant, not module-validated. ML-KEM-1024, ML-DSA-87 and AES-256-GCM execute in a library whose validated configuration is not the one we link; ChaCha20-Poly1305, HKDF-SHA-512, X25519 and the hash functions execute in separate audited implementations. Every primitive passes a pinned known-answer test at every launch of the app and every start of the relay, and a failed test stops the process. No QERYX module holds a FIPS 140-3 certificate.

Not yet, independently. The review is ours: an internal pre-evaluation against the NIAP Common Criteria bar, whose latest pass (2026-06) reads READY WITH DEVIATIONS on the algorithm layer — five documented deviations, enumerated under transparency — and carries a longer list of assurance-layer findings tracked to closure. No accredited laboratory has been engaged. The evidence bundle an evaluator would read lives in the Trust Center.

Key encapsulation runs on the FIPS-lineage library, clear of the KyberSlash class of decapsulation-timing flaws published against early lattice reference code. Verify paths use constant-time comparison, and leakage is measured with a fixed-versus-random test-vector leakage assessment over the ML-KEM, ML-DSA, AEAD, HKDF and X25519 hot paths, gated against a pinned baseline on every change to them. On-silicon leakage assessment is an accredited-lab step and has not been performed; the evidence sits in the evaluator bundle at /trust.

Protocol drafts are authored (draft-qeryx-*-00/-01); submission packages are prepared. Wire formats, test vectors, and design specs publish at /research as they land — dated, versioned, with a what-changed log.

Not yet, and we say so. Machine-checked symbolic modeling of the handshake and ratchet composition is planned; until then the security arguments anchor to the standards and the published analyses. When a proof exists it will be linked, not paraphrased.

No. The server is a dumb encrypted blob relay. It cannot read messages. Keys exist only on your devices.

Undelivered messages: ciphertext blobs plus routing metadata under the published retention ladder. Delivered messages: gone from the relay database once the purge has run, about 25 minutes after the delivery receipt, leaving a destruction receipt with a hash of the message’s id and its times for thirty-seven days. A group message, sealed to each member by default, and a message read with Stealth Mode on or read receipts off are retired without a receipt the relay can match, so their ciphertext waits for the offline horizon. Photos, videos and files: each stays stored apart, encrypted, with an upload record that names its uploader, until its own expiry, up to 45 days after upload, even after its conversation is destroyed, unless its sender deletes it sooner. Destroyed conversations: the rows the relay can tie to the conversation are deleted, and where the relay’s own at-rest envelope wrapped them, that envelope’s epoch is retired; a one-to-one message, sealed by default, names neither its sender nor its conversation, so the destroy does not reach it, and one still waiting, or read with Stealth Mode on or read receipts off, stays to the offline horizon. A database backup taken before a purge still holds the rows as they were. Reading content requires breaking both X25519 and ML-KEM-1024.

Group names and descriptions and all content are end-to-end encrypted; the group avatar, the admin and owner identifiers, and the roster of accounts each conversation delivers to are held by the relay for routing. Sender identifiers are stripped from the stored message row (sealed sender), though the relay authenticates the sender at send time and keeps a per-direction pair counter for up to 180 days. Sealed sender covers text-class messages and small payloads: an image, and any voice or video frame over the envelope budget, is delivered on a lane that does name the sender to the relay for as long as the row lives. Undelivered messages queue with routing metadata under a published retention ladder.

The outer envelope is addressed to the recipient alone; the sender's identity is readable only after decryption. Sender identifiers are stripped from the stored message row (sealed sender), though the relay authenticates the sender at send time and keeps a per-direction pair counter for up to 180 days, and the relay routes by opaque identifiers.

There is no lawful-access endpoint, and no plaintext store to point one at. What a request can actually yield is the qualified list above. Formal posture: NIAP READY WITH DEVIATIONS on our own pre-evaluation — not a completed EAL 4+ certification. The deviations are enumerated; no accredited-laboratory evaluation has begun, and the evidence bundle is being completed for one.

Deleting a one-to-one chat, or a group for everyone as its admin, retires its at-rest envelope epoch, so a compliant relay can no longer unwrap that epoch's rows, and the relay deletes, in one transaction, the rows it can tie to the conversation; a member who deletes a group leaves it, and the relay keeps the group's rows for the members who remain. A one-to-one message, sealed by default, names neither its sender nor its conversation, so the delete does not reach it: it leaves on its own clock, within about 25 minutes of its delivery receipt, or at the 30-day horizon if it is still waiting or was read with Stealth Mode on or read receipts off. Each photo, video or file stays until its own expiry, up to 45 days after upload, unless its sender deletes it sooner. Deleting your account hard-deletes your server-side record in one transaction — messages, key bundles, signing keys, devices, memberships, files and the push token — and removes your identifier from every conversation roster in the same transaction, with no grace period. The transparency log is append-only and is not rewritten: the entries recording that your keys once existed stay in it, because a log that can be edited is not a transparency log.

Messages already delivered to your contacts live on their devices. Deletion cannot reach into someone else's phone, and we will not pretend otherwise.

You will hold two identifiers. The Profile ID is public — share it with anyone you want to reach you. The SERPENT ID is secret: it never appears in chat and never leaves ceremony surfaces. Discovery is by what you choose to share.

No. Backups are encrypted on your device, and the local backup passphrase is stretched with Argon2id (m=256 MiB, t=4, p=2 — RFC 9106) before it touches a key. Without your passphrase the backup is noise to everyone — including us.

We cannot recover your messages or your account if you lose your device and your Secret Phrase. There is no key-escrow and no master reset.

With the passphrase, recovery will take three steps: recover your access.

No. Only you hold it. A reset path for us would be a reset path for anyone who could compel us — the absence is the feature.

Once QERYX arrives, you will choose Restore on the new device and enter your Secret Phrase; the backup decrypts on-device. The full procedure with its honest limits: recover your access.

One device per identity at first; linked devices are on the roadmap. The carrier model makes multi-device harder on purpose — recovery state cannot be centralized server-side.

Once QERYX arrives, you will verify each contact once, in person, through the Entangled pairing: the two devices compare the check for you, and from then on it runs on its own. Key changes surface in the key transparency log, so a swapped key is a visible event, not a silent one. Full ceremony: verify your keys.

Once QERYX arrives, deletion will sit at Profile → Settings → Delete Account. It hard-deletes your server-side record in one transaction and removes your identifier from every conversation roster, with no grace period; the transparency log is append-only, so the entries recording that your keys once existed stay in it. Step by step: delete and rotate.

Not as a control yet. Rotation is in development; to retire an identifier you will delete the account and start again. Your ML-DSA-87 identity key will roll on its own schedule, signed by the key it replaces — the transparency-log append of that transition is staged — which is why your contacts will see a key-change notice and should verify your keys again.

Three-hop onion-routed circuits with a fresh ML-KEM-1024 encapsulation per hop and an ML-DSA-87-signed relay directory your device checks against a pinned key. Each hop peels exactly one layer.

It is in development; QLEAP arrives in a later update. The relays, the directory, and the per-hop KEM are already written. QLEAP.

An eSIM provisioned through QERYX, with six-bearer failover. Carrier provisioning is not enabled yet: the courier reports the server’s provisioning rung honestly and never invents a session. HydraSIM.

The QERYX assistant, in development. The framing is deliberate: the page claims nothing past what is built. Qaduceus.

The QERYX browser, in development. The page is a spec, and it says so plainly. Wadjet.

Email support@qeryx.com with what you did, what you expected, and what happened.

Email support@qeryx.com with SECURITY in the subject — the address published in our security.txt. We practice coordinated disclosure and will not pursue good-faith researchers. Procedure and safe harbor: report a vulnerability.

press@qeryx.com. The press kit and materials live at /press.

Write to support@qeryx.com. A human reads every message, and the questions we keep receiving get added to this page.