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 v2), though the relay still authenticates the sender at send time, 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, subjects, avatars, and all content are end-to-end encrypted; the relay holds only opaque routing identifiers; sender identifiers are stripped from the stored message row (sealed-sender v2), though the relay still authenticates the sender at send time. Undelivered messages queue with routing metadata under the published retention ledger below.

Account creation requires an invite code issued by an existing member. The code is single-use. 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 stores nothing about who issued 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	Nothing is written — the sealed message is relayed in memory to your recipient’s live connection	The moment of relay
Offline queue	The sealed ciphertext plus the opaque routing identifiers needed to deliver it	Until delivery, and at most 30 days from creation (purge job)
Delivered via queue	The delivered row remains, marked delivered, until the same purge ceiling removes it	At most 30 days from creation
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

The designed retention ladder — deletion at the moment of delivery confirmation, and shorter queue ceilings underneath it — is engineering in progress. This policy describes the system as it runs; when the ladder ships, this table becomes the ladder. Deletion under the purge job is a hard database delete, a true erasure rather than a soft-hide.

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 (m=512 MiB, t=2, p=4)	Derive device-held keys from a user-chosen passphrase

Because the shared keys are established between devices and never escrowed on the server, the relay’s knowledge of your conversation content is mathematically zero, not policy-zero.

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: a tuple of an opaque account identifier and an encrypted state blob. 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 v2), though the relay still authenticates the sender at send time. While a message waits in the offline queue, its row carries the opaque routing identifiers needed to deliver it; those rows leave under the retention ledger above. We do not correlate participants across conversations.

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. 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 transiently at the edge for delivery and abuse defense; we do not build user-linked IP histories.

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, aggregate counters, opaque routing identifiers for messages still inside the offline queue, the encrypted assistant history blob we cannot read, an encrypted push wake token, and the hash of a redeemed invite code — 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 notify you at least 30 days before any material change to this policy via an in-app banner — the canonical notification channel, because we do not store an email address to message you at. The current version and its effective date are always shown at the top of this page.

Document history

• 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