Privacy Policy

• No plaintext of a message, call, or media file you exchange with another person is ever transmitted to or stored by QERYX.
• What you type to the Qaduceus assistant, and any image you attach to it, leaves your device readable and is forwarded to an AI processing provider. Your conversations with people never take that path.
• No advertising identifier is requested. No ad SDK is embedded.
• No analytics, usage-tracking, product-event, or crash-reporting SDK is embedded in the app.
• This version sells nothing. There is no in-app purchase, no card processor, and no payment record of any kind.
• We do not sell, rent, broker, or trade any user data. There is no data-broker relationship to disclose because none exists.
• Who-you-talk-to lives inside sealed envelopes: 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 messages that wait for an offline device queue with routing metadata under the retention ledger published below.

QERYX operates as a carrier, not a service that reads your content. The end-to-end encryption runs between devices; the relay moves opaque ciphertext the way a postal carrier moves sealed envelopes — without opening, reading, or inferring. The relay is structurally unable to decrypt your messages because it never holds the keys.

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.

During the invited cohort, account creation takes a single-use invite code issued by QERYX. The relay stores the hash of a redeemed code bound to the profile identifier that redeemed it, so a code cannot be spent twice; it records nothing about the person who passed it to you.

The QERYX app carries an assistant, Qaduceus, on its own tab. When you send it a turn, the text you typed travels to the relay readable and is forwarded to an AI processing provider, which produces the reply. Images you attach to that turn — from your photo library, the camera, the clipboard, or a drag — travel the same path readable, as image blocks alongside your text, and are readable by that provider for the length of the turn. This site names no outside vendor anywhere; the subprocessor register in the Trust Center is the one place that will, and this provider is in it when it publishes.

Each turn is metered server-side against your account’s plan. Where a plan is metered, a counter row keyed by the same opaque routing identifier as your account records that a question was spent — the fact of the turn, never its content.

Your assistant conversation history syncs across your own devices as a blob encrypted on your device before upload. The relay stores that blob and cannot read it. It is deleted 90 days after its last update, and immediately when you delete your account.

The boundary that makes the rest of this policy true: a conversation with a person never enters this path. Nothing you write to a contact, a group, or a channel is sent to any model or any provider, and no photo you send to a person is readable by anyone but the recipients. The assistant is a separate tab, and the traffic it generates is the traffic you deliberately send it.

The app’s bundled privacy manifest declares exactly three linked collected data types — an account identifier, other user content, and photos or videos. The second and third are this section.

This table states what the running system does today — present tense, verified against the relay code, corrected here whenever the code changes.

What the relay holds, and for how long

Delivery path	What the relay holds	For how long
Online delivery	The sealed row is written before the relay attempt, served to your recipient’s live connection, retired at their acknowledgment, and hard-deleted by the sweep	Gone within 10 to 25 minutes (10-minute grace, 15-minute sweep)
Offline queue	The sealed ciphertext plus the opaque routing identifiers needed to deliver it	Until delivery, and at most 30 days from creation — the horizon is operator-tunable between 1 and 90 days and published by the relay at /api/v1/transparency/retention
Delivered via queue	The delivered row is soft-deleted at the acknowledgment and hard-deleted by the lifecycle sweep — the FSOR erasure event	Gone within 10 to 25 minutes of the acknowledgment (10-minute grace, 15-minute sweep)
Retired without a matching receipt	A group message, sealed to each member by default as a row of its own that the member’s receipt does not match, and a message read with Stealth Mode on or read receipts off: the row is retired without a receipt and kept	Until the 30-day offline horizon, then hard-deleted by the sweep
Photos, videos, files and group voice notes	Each file, encrypted on the sender’s device and stored apart from its message, with an upload record naming the uploader, the file type, its size and its times	Up to 45 days after upload, whether or not the message was delivered and even if its conversation is destroyed; sooner only when the uploader deletes it, by deleting the message for everyone, through a chat timer, or by deleting the account
Assistant history	Your assistant conversation blob, encrypted on your device before upload — the relay cannot read it	Until 90 days after its last update (purge job), or the moment you delete your account
Push wake token	Your device push token, encrypted at rest, plus a hash used to recognise it again	Until you sign out or delete the account — and in any case a 60-day idle ceiling from the last successful push, 14 days for a token never validated
Invite redemption	The hash of the code you redeemed, bound to the profile identifier that redeemed it	For the life of the account
Pair delivery counter	An opaque per-direction pair row carrying the send-time sender, used to gate calls between strangers	About 180 days idle
Delivery idempotency ledger	The one relay table that records a sender-to-recipient edge, so a retried send is not delivered twice	1 day
Delivery-receipt park	Receipts parked for a peer that has not yet fetched them	30 days
Conversation-destruction log	The hashed conversation identifier, epoch pair, leaf count and time of every destruction — the record that proves what was erased	thirty-seven days (the offline horizon plus seven), then swept

Every number in this table is the value the relay enforces: the relay publishes the same ladder from the constants its sweeps run on, at /api/v1/transparency/retention, and this page reads those constants at build time. Deletion under the purge job is a hard database delete rather than a soft-hide. The database does not overwrite the space a delete frees, so until that space is reused, and in any write-ahead log or backup taken before, the deleted row’s bytes remain: end-to-end ciphertext the relay holds no key to, beside the row’s routing columns.

Every conversation is end-to-end encrypted with a hybrid post-quantum construction. The names below map to published cryptographic standards so the claims are auditable.

Primitives, by layer

Layer	Primitive	Purpose
Key encapsulation	ML-KEM-1024 (FIPS 203) + X25519 hybrid	Establish shared keys resistant to both classical and quantum attack
Identity signatures	ML-DSA-87 (FIPS 204)	Sign identity keys; anchor the key-transparency log
Message encryption	ChaCha20-Poly1305 (RFC 8439)	Authenticated encryption of message and media payloads
Passphrase hardening	Argon2id — vault floor m=128 MiB, t=3, p=4, calibrated upward on the device; local backup m=256 MiB, t=4, p=2; relay sign-in hash m=64 MiB, t=3, p=4	Derive device-held keys from a user-chosen passphrase; hash the sign-in secret on the relay

Because the shared keys are established between devices and never escrowed on the server, the relay cannot decrypt your conversation content — a property of the construction, not a policy promise.

We are precise about this. We do not overclaim (“we collect nothing at all”) nor underclaim. The following is the complete list of what the QERYX infrastructure handles.

Account identifiers

To route encrypted packets to the right device, the relay maintains an opaque account record: an opaque account identifier, an encrypted state blob, and a one-way Argon2id hash of the sign-in secret your device stretches before it is ever sent (relay m=64 MiB, t=3, p=4). It does not contain your name, phone number, or email, because QERYX does not ask for any of those at sign-up. Your private SERPENT ID stays on your device; your public Profile ID is a handle you can retire by creating a new identity.

Relay metadata (minimized)

To deliver an encrypted packet, the relay sees the destination it must route to and the size of the opaque payload. 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. While a message waits in the offline queue, its row carries the account identifiers needed to deliver it; those rows leave under the retention ledger above. The relay holds, per conversation, the set of account identifiers it must deliver to. We do not build cross-conversation participant profiles, and we publish that the roster makes it possible.

Assistant content

The text and images you send to the Qaduceus assistant, the counter that records a metered turn was spent, and the encrypted history blob. Stated in full in section 03. This is the only readable user content the relay receives.

Push wake tokens

So a message can reach a phone with the app closed, the relay holds the device push token issued by your platform, encrypted at rest, together with a hash it uses to recognise the same token again. The wake itself carries a generic alert — no sender, no message content, no conversation identifier. The notification decrypts on your device. The wake also carries an opaque grouping token derived per device, which lets the phone fold duplicate alerts and cannot be correlated across devices. Deleting your account drops the token in the same request, and a sweep removes any token that has gone 60 days without a successful push.

Invite redemption

Registration consumes a single-use invite code. The relay stores the hash of that code bound to the profile identifier that redeemed it, which is what makes the code single-use and an interrupted sign-up retryable. It does not link you to whoever gave you the code.

Operational metrics (cardinality-of-one)

To keep the service running and defend against abuse, the infrastructure keeps coarse aggregate counters such as total requests per minute and total bytes transferred per hour. These identify no one. Connection addresses are seen at the edge for delivery and dropped: the API host writes no access log, and a failed sign-in records only a short hash. Traffic that hits one of the decoy endpoints planted for intruders is recorded with its address for ninety days; ordinary app traffic never reaches them. We build no user-linked address history.

Payments

This version sells nothing. There is no in-app purchase, no subscription, and no card processor in the data path, so no payment record of any kind exists for your account. When paid tiers ship, this section is rewritten before they do, and the named register of payment and infrastructure subprocessors publishes in the Trust Center.

• Message, voice, video, or photo content in plaintext from your conversations with people — the relay only ever sees ciphertext. Images you attach to the assistant are the stated exception in section 03.
• Your address book or contacts — there is no “sync contacts” feature; the app does not read your address book.
• Your location — location is shared only if you manually attach it to a message, and then only end-to-end encrypted to your recipient.
• An advertising identifier — it is never requested.
• Browsing or search history — search runs on-device against a local encrypted index.
• Crash reports and diagnostics — no crash-reporting SDK is embedded in the app, and no crash or diagnostic report is transmitted anywhere.
• Persistent diagnostics or usage analytics — no analytics SDK is embedded in the app.

Nothing for advertising, profiling, or brokerage. There is no advertising partner, no data broker, and no analytics vendor in the data path. There is no payment processor either, because this version sells nothing. One third party receives data: the AI processing provider that serves the Qaduceus assistant, and it receives only the turn you send the assistant — your text, and any image you attached to it. It receives no conversation with a person, no contact, and no key.

The infrastructure is designed so that we cannot read the content of your conversations. A hostile legal demand recovers opaque ciphertext blobs, the encrypted photos, videos and files still within their lifetime with the upload record that names each uploader, aggregate counters, the per-conversation participant roster and the group admin, owner and creator identifiers, routing identifiers for messages still inside the offline queue or retired without a matching receipt, group avatar images, the per-direction delivery counters and the delivery-receipt rows listed in the retention ledger, the encrypted assistant history blob we cannot read, an encrypted push wake token, the hash of a redeemed invite code, and the signed destruction records that prove what was erased and when — each under the retention ledger above. We respond to lawful requests in the only way the architecture permits:

We cannot disclose what we do not hold. This is the practical meaning of the carrier model. The public record of requests lives in the Transparency Report.

• Delete your account. Profile → Settings → Account → Delete Account runs a typed-and-held ceremony with a fresh password proof, then a single server transaction that erases every row the relay can attribute to you — messages, key bundles, signing keys, devices, memberships, files, the encrypted assistant blob, and the push token. There is no grace period on that path and no support route to undo it. The one exception is the panic-wipe path inside the capture scenario, which marks the account deleted and lets a background sweep run the same erasure a short interval later (60 minutes by default), because the signed notice to your peers has to reach devices that are offline before the row disappears underneath it. The key-transparency log is append-only by construction and is not rewritten: entries recording that your keys once existed remain in it.
• Retire an identity. This version ships no in-app rotation control. The way to retire an identifier today is to delete the account and create a new one under a fresh invite — a hard erasure with no recovery, not a rename. When rotation ships, it is described here before it is shipped.
• Export your data. Profile → Settings → Encrypted Backup writes a .qeryxbackup file sealed under a passphrase you choose at export and only you hold. We cannot read the export, and we cannot recover the passphrase.
• Analytics and ads opt-out. Not surfaced as a toggle because analytics are not collected and ads are not shown — there is nothing to opt out of.
• Do not use the assistant. The one path that carries readable content off your device is a tab you choose to open. Not opening it is a complete opt-out, and everything else in QERYX works unchanged.

QERYX is intended for people 17 and older. We do not knowingly create accounts for anyone under 17. Because we do not collect identifying personal information at sign-up, we rely on platform age-gating and on this stated minimum age.

QERYX is operated as a worldwide service. The governing jurisdiction of the operating entity is stated in our Terms of Service. Where mandatory local data-protection law (for example, GDPR for people in the European Economic Area) grants you rights of access, rectification, erasure, and portability, those rights are served by the in-app controls above; for content, the cryptographic design already minimizes what could be subject to such a request.

We publish any material change on this page and in the changelog at least 30 days before it takes effect. We hold no email address to write to, so this page and the version block at the top of it are the notification channel.

Document history

• v1.3 · 2026-10-01

  The retention ledger (section 04) corrected against the relay: a delivered row is counted from the acknowledgment; a group message sealed to each member, and a message read with Stealth Mode on or read receipts off, wait for the offline horizon; photos, videos, files and group voice notes are listed with their own lifetime. The purge job is described as a hard delete that does not overwrite the space it frees. The legal-request enumeration and the standard response (section 09) name those files and their upload records, and the enumeration names the messages retired without a matching receipt.

• v1.2 · 2026-08-27

  The assistant path published in full (section 03): readable text and attached images, server-side metering, the 90-day encrypted history blob, and the boundary that keeps conversations with people out of it. Push wake tokens, invite-code redemption, and the assistant blob added to the retention ledger and to the legal- request enumeration. Payments section corrected — this version sells nothing. Crash-diagnostics section removed: no crash-reporting SDK is embedded. Deletion, identity-rotation, and contact statements corrected against the shipping build. Effective date fixed to the launch date.

• v1.1 · 2026-07-17

  Retention and metadata wording corrected to state the running system exactly (published retention ledger; sealed-sender and routing-identifier wording). Payment-processor names moved to the Trust Center subprocessor register. Canonical URL moved to qeryx.com/legal/privacy.

• v1.0 · 2026-06-04

  First published draft.

One mailbox, read by the people who build QERYX. Put PRIVACY in the subject line for a question about this policy, or SECURITY for a vulnerability report — scope and safe harbor are on the bug bounty page.

• support@qeryx.com