Entanglement Protocol — QERYX Trust Center

Know what QEP-1 is

Two phones agree a post-quantum session through a signed, nonce-bound ceremony whose accept travels sealed, so the initiator's open of it is the first key confirmation. Then a cloud processor measures entangled pairs in bases the two phones chose and committed before the round; each phone receives only its own half's outcomes, sealed to its own X25519 + ML-KEM-1024 bundle key; the phones sift and check their halves over the sealed channel, and a 256-bit block is folded beside the post-quantum root, never instead of it, under a certificate both ML-DSA-87 identities sign and a public log witnesses. Two blind tokens, one from each side, open one round. A bond never blocks a chat.

This is not QKD. Not quantum networking. Not quantum teleportation. We do not violate the no-communication theorem. The processor's vendor and our mint see every outcome before it is sealed, so the block is never the sole secret; the outcomes reach each phone sealed under X25519 + ML-KEM-1024, so the bond adds no secrecy against a future quantum computer beyond ML-KEM. It is not device-independent. The operator's log is one party. Malware on a phone is out of scope.

Verify what is published

Without an account: every published receipt's signature and aggregate, the mint's key and build hash, and the vector file against either reference implementation. With the account of one side of a pair: that pair's certificate and everything the log holds beside it. Never, from any artefact: an outcome, a block, or a key.

Artefacts, what each proves, and its limit
Artefact	Where	What it proves	Limit
The latest round receipt	GET /api/v1/qpu/chsh/latest, unauthenticated	A round was minted on the named processor: the aggregate S with its standard error, the pair counts, the build hash and the beacon pulse, under an ML-DSA-87 signature by the operator key.	The aggregate is the mint’s estimate over its own view of the round; the phones decide on their own subset. A simulated receipt says it simulated and proves the road, not entanglement. Until the first round mints, the door answers a stable 404.
The mint’s identity	GET /api/v1/bond/mint, unauthenticated	The mint’s hybrid public key and key id, the month’s token key, the pairs per bond, the build hash and where it came from, and the limits every receipt states.	A hash of the executable names a build; the reproducible-build recipe that turns it into a proof is specified and being built.
The vector file	crypto-core/vectors/bell-bond-v1.json, in the source tree	Seven cases — an ideal source, a noisy source, a source too noisy, a local-hidden-variable source, a tampered reveal, two rounds’ halves, too few pairs — with every intermediate value; both blocks reproduce from side A and side B.	The file binds the two reference implementations; the Swift reference reproduces every case (QEP-1 §5.13), and the file is the norm where the two would ever differ.
Your own pair’s certificate	GET /api/v1/kts/bond/mine?peer=, with the account of one side	The certificate bytes, both ML-DSA-87 signatures, the leaf, the inclusion proof under the log’s signed root, every witness signature in both shapes, the external timestamp token and the pulse.	Served only to the pair. The doors are mounted in the tree’s relay; no app reaches them yet, and this page will say when one does.
A bond’s public leaf	GET /api/v1/kts/bond/leaf/{hash}, unauthenticated	The leaf at its sequence number, the inclusion path under the operator’s signed root, every witness signature in both shapes, the external timestamp token, and whether a re-mint superseded it.	A digest and the tree’s word about it: no certificate bytes, no identity, no round. The pair hands the auditor the hash; the public tree links a leaf to nobody.

two unauthenticated reads against a relay

curl -s $RELAY/api/v1/qpu/chsh/latest
curl -s $RELAY/api/v1/bond/mint

$RELAY stands for the address of a relay that carries the bond. A receipt's signature verifies under the operator's ML-DSA-87 key with the receipt context named in the mint's own answer; its canonical bytes are laid out, field by field, in QEP-1 section 7.6. Until the first round mints on a deployment, the first read answers a stable 404 whose error field reads no_transcript_available.

Read the algorithm in one table

Every function is pure: bytes in, bytes out, no clock and no randomness, so the Rust reference, the Swift reference and the vector file can be checked against each other. The exact bytes of every domain label, and every constant with the symbol it comes from, are in QEP-1 sections 2.3 and 5.

The bond's beats, in order
Beat	What the code does	Limit or note
Settings	three angles per side; each phone draws one index per pair from its own randomness	uniform over {0, 1, 2}, without modulo bias
Commitment	SHA3-256 over a domain label, a 16-byte salt and the settings string, published before any pair is measured	checked in constant time at reveal; an invalid index refuses the round
Sift	two of nine setting combinations are key pairs, four are the CHSH test, three are discarded	about 2N/9 key candidates and 4N/9 test pairs per N pairs
Error sample	one kept position in ten, chosen by a SHAKE256 stream over the round id and both commitments; the round fails above 11 percent	the sampled bits leave the key
Bell check	S over the four CHSH buckets with the binomial standard error; at least 800 pairs, S ≥ 2.2, and S − 3σ > 2.0; the value must equal the aggregate the mint signed for the round	a local-hidden-variable source reached 2.222 by fluctuation in one case; the 3σ edge refused it. The peer reveals its outcomes after it holds this phone’s, so the mint’s signed aggregate over the same pairs is the check on the peer’s word
Reconciliation	a syndrome under a Gallager LDPC code, column weight 4, row weight from the error estimate; the leak is charged bit for bit; a 64-bit key check over the reconciled key crosses beside the block commitment	the form both references carry and the vector file binds; the key check is not charged to the budget, and the budget is asymptotic accounting, not a finite-key bound
Budget	floor(n(1 − h(q))) − leaked − 64 must reach 256	a short budget produces no block and changes nothing about the chat
Block	the first 256 bits of a Toeplitz product whose diagonal is a SHAKE256 stream over the round id and both commitments	linear over GF(2); a commitment of the block is exchanged before either phone folds
Certificate	205 bytes plus the processor name: round id, block commitment, transcript hash, both identity digests, S, the pulse, the mint time; two ML-DSA-87 signatures under one context	the log refuses a second live certificate for a pair; a re-mint after a device change supersedes and stays readable

Read the documents and the references

The library and the protocol implementation are source-published for review. The paths below are repository paths.

The protocol: docs/protocol/QEP-1.md — conventions and labels, actors, the ceremony's frames and state machines, the algorithm, the phone's round, the mint, the log, the specified parts, the eight security goals with their limits, the audit face, the false claims, the rungs, the vectors, and the implementation status as read.
The words: docs/protocol/QEP-1-WORDS.md — every sentence the ceremony, bond, path, possession and erasure surfaces print, each with its limit.
The design: docs/superpowers/specs/2026-09-17-qeryx-entanglement-protocol-design.md and docs/superpowers/specs/2026-09-16-bell-bond-ceremony-design.md.
The reference implementations: crypto-core/src/bell_bond/ (Rust: settings, sift, the CHSH estimate, reconciliation, amplification, the certificate, the composed round, the C ABI) and BellBondMath in ios/Qeryx/Services/Crypto/QRatchetBellFFI.swift (Swift).
The vector file: crypto-core/vectors/bell-bond-v1.json — version 1, twelve rules stating the algorithm in words, seven cases, and the words section the pages print from.
The mint and the log: backend/src/bond/ (the doors, the envelope, the round state machine, the batch, the receipt, the ledger, the tokens) and backend/src/services/kts/bond_log.rs with timestamp.rs (the leaf, the handle, one certificate per pair, the witness shapes, the external timestamp).
The runner: tools/quantum-beacon/bond_round.py and README-BOND.md — the processor road, with a simulator that needs no account and says it simulated.

Run the conformance checks

The conformance binary replays the vector file, verifies every published receipt, verifies a certificate against the log's inclusion proof and its external timestamp, and prints the limit sentences the pages print — one line per check, PASS, FAIL or SKIP, and a non-zero exit on any FAIL. It is in the tree at crypto-core/src/bin/qep_conformance.rs, built from the same crate the phones and the mint link; the walk is docs/protocol/QEP-AUDIT-RUNBOOK.md. It runs against a relay that carries the bond; no app carries it yet.

qep-conformance — in the tree, built from source IN THE TREE — NOT YET IN THE APP

qep-conformance vectors
qep-conformance receipts --relay $RELAY --since 0
qep-conformance certificate --relay $RELAY --leaf <hex>
qep-conformance words
qep-conformance hash --file ./qeryx-backend.audit

Public receipt history, the mint key door, the public leaf door — mounted in the tree, opening with the first app that carries the bond

Three more unauthenticated doors sit beside the two above: GET /api/v1/bond/receipts?since=0 (every receipt, paged), GET /api/v1/bond/mint-key (the receipt-signing key beside the build hash and the receipt's byte layout) and GET /api/v1/kts/bond/leaf/{hash} (the public leaf with its proof, its witness signatures and its timestamp). The receipts door serves no per-bucket tallies yet, so the binary names S rather than recomputing it. The reproducible-build recipe is tools/quantum-beacon/REPRODUCIBLE-BUILD.md and names its own limit: the build is pinned, not yet proven bit-reproducible.

Read what is never claimed

Never written — and what is true instead
Never claimed	What is true
“Quantum-secured chat”	A vendor-attested Bell sample, published to the transparency log and read back, folded beside a post-quantum key when both phones fold; at first the block is certified and held.
“The key never existed anywhere but the two phones”	The processor’s vendor and the mint saw every outcome before it was sealed; the block is never the sole secret.
“Device-independent”	The settings come from the phones, the measurement from a vendor, the receipt from the mint. A trusted node, printed as such.
“QKD”	The outcomes cross to each phone sealed under X25519 + ML-KEM-1024. The bond adds no secrecy against a future quantum computer beyond ML-KEM; its value is the block’s independence from the recorded handshake.
“The log proves the bytes are gone”	An erase receipt, when it ships, proves the erase was recorded after the pulse it names and before the next leaf. Nothing proves bytes are gone from a disk QERYX does not control.
“In the app today”	QEP-1 is in the source tree and not yet in the app. The app carries it once the relay and the app that fold it are ready.

The same list is pinned in source on the phone and in the copy gate this site builds through. A protocol document that lists no limits has not been reviewed hard enough.

07The record — the questions an auditor asks first

Ask the hard ones.

Is this QKD?

No. In QKD the two ends measure the halves themselves and the key never rests with a third party. Here a processor measures both halves and its vendor and our mint see the outcomes for the instant before they are sealed, which is why the block enters beside the post-quantum key and never instead of it. The rungs that move the measurement to the ends are listed in QEP-1 section 15; only the first rung is built.

What does the Bell check prove, and what does it not?

It proves that the outcomes each phone received correlate the way entangled pairs measured in the committed settings do, three standard errors above the classical bound of 2, and that the settings were committed before anything was measured. It does not prove that no one else holds those outcomes, and it is not device-independent.

Can I verify my own chat's certificate?

With the account of one side of the pair, on a relay that carries the bond: the certificate bytes, both signatures under the two identity keys, the leaf, the inclusion proof under the signed root, the witness signatures, and the RFC 3161 token, which your own tool verifies against the authority's roots (the relay asked for it over plain HTTP and stored it unverified, and the phone prints it as the relay's record). The phone runs the same checks and compares its read-back with the peer's before it prints anything.

Next: the protocol overview — section 11, the bond stated with its limits