Qlyphs Verified by design
How purchase proofs bind an offer to state signed by trusted witnesses, and what remains trusted.
How does your wallet know an offer is real before paying for it?
Token balances and reservations are computed on top of Quantus. A false reservation could ask a buyer to pay for tokens they will not receive, so the signing wallet requires more than an unsigned server response before a purchase.
Replay from a fixed checkpoint
QLYP interprets blocks after a published activation anchor, in order. The anchor itself is excluded. Identical inputs and rules produce identical state. Provisional views may change during a reorganization; purchase proofs bind a finalized checkpoint.
- Sent 3 QTCblock #184,222
- Received 12.5 QTCblock #184,220
- 01 / 05
Blocks keep arriving
New Quantus blocks can be provisional and may be replaced by a reorganization. A configured node reports both its best head and finalized checkpoint; their gap is compressed in this illustration.
- 02 / 05
Finalized and provisional are separate
Witness proofs describe finalized state. Finality is reported by the configured node, not assumed after one newer block. The service may also expose provisional state, which can change before finality.
- 03 / 05
Read in order, from a fixed start
Replay begins with empty QLYP state at the excluded activation anchor. The next block is the first interpreted block; subsequent finalized blocks are processed in order without gaps.
- 04 / 05
The same chain gives the same result
Identical blocks and protocol rules produce identical state. This makes replay reproducible, but does not independently verify node consensus or establish that a witness implementation is correct.
- 05 / 05
Attestation keys are not spending keys
An indexer does not need user spending keys to derive balances. Witnesses have their own attestation keys, which authenticate state and cannot spend from a user account.
Finality comes from the configured node. Replaying state is reproducibility, not independent consensus verification. A service can maintain provisional state while keeping its durable finalized checkpoint separate.
Two trusted witnesses
The development deployment provides TypeScript and Python witness implementations. A purchase policy requires signatures from two configured witness operators over the same state root and finalized checkpoint. Each uses ML-DSA-87. The policy binds the public keys, network, runtime, rules and freshness limits in the wallet build; a website cannot substitute a key.
Separate implementations reduce shared implementation risk. Independent operation and separate node infrastructure are deployment requirements, not properties established by the code alone. The signatures authenticate what those witnesses attest; they do not prove the witnesses are honest or replace the chain's consensus.
Fresh, bound and never rolled back
Each witness statement binds its state root to the network's genesis, the activation anchor, the runtime, the rules, the finalized block and a fresh 256-bit challenge chosen by your wallet. A statement is valid for at most 60 seconds. The wallet also remembers the highest checkpoint it has accepted, so a witness cannot later show it an older state, or two different states at the same height.
Selective proofs: only what you are buying
In development
Selective proofs (QPA2) are being developed together with open listings on a development track.
Today the wallet checks the reservation inside the full signed state. The next proof format commits to that state in eight sections (assets, balances, sequences, multisigs, tickets for reservations, symbols, inscriptions and listings), each with its own SHA-512 Merkle tree. The witnesses sign one root over the section roots and their sizes. Your wallet then receives only the listing it is buying, its asset and their inclusion paths, instead of a whole snapshot.
- 01 / 05
One entry arrives
The wallet receives the reservation it is about to buy and the proof data needed to check it. This small tree illustrates how one entry can be bound to a signed state root.
- 02 / 05
A neighbour joins it
Along with the listing comes one hash per level of the tree. The wallet hashes the listing together with its neighbour, the entry next to it. The result is a new hash that stands for both of them.
- 03 / 05
And again, level by level
It repeats the step: the result is paired with the next hash it was given, and so on, climbing one level at a time. Proof size grows with tree depth. This drawing has a few entries; it does not establish a latency guarantee.
- 04 / 05
It reaches a root
At the top there is a single hash, the root. The wallet computed it itself, from the very listing it will pay for. It is a fingerprint of the whole market that changes if any single entry changes.
- 05 / 05
The witnesses’ root must match
That root must match the checkpoint signed by both trusted witnesses with ML-DSA-87. A changed entry fails the proof check. Valid signatures authenticate what the witnesses attested; dishonest witnesses or compromised implementations remain risks.
A path needs at most one sibling hash per tree level, so it grows with the logarithm of the section size:
- Sibling hashes in one path, at most
- 17
- Path size, SHA-512
- 1,088 bytes
A section of 100,000 entries needs at most 17 sibling hashes. The whole reply also carries headers, entries and signatures, and is capped at 256 KiB. The service that gathers the proofs is untrusted: it cannot swap witness keys, and a missing entry is an error, never an empty balance.
Each check rules something out
| Check | What it rules out |
|---|---|
| Two signatures from keys compiled into the wallet | A website or server inventing a state |
| Both witnesses sign the same root | One faulty or compromised replay engine |
| A fresh challenge, at most 60 seconds old | Replaying an old, once-true statement |
| A finalized block, never older than the last one seen | Paying on a state that can still be reorganized or rolled back |
| The reservation is found in the signed state | An entry that was changed or made up |
| The purchase is built from the proven terms | A site changing the price, amount or payee |
What the wallet checks before paying
- The required witness signatures against the compiled trust policy.
- Agreement on the state root, finalized checkpoint and bound network/runtime/rules, within the policy's freshness limits.
- The reservation proof and named buyer, then the native proposal's exact call, membership, approval state and expiry through its configured Quantus node.
- The purchase it constructs against those committed terms, followed by your approval on the wallet's own screen.
Any failed required check refuses the purchase. Builds without the purchase policy refuse purchases, and witnesses remain disabled on mainnet. A valid proof authenticates an attested checkpoint; it cannot guarantee a later transaction will still succeed. Check the eventual transaction result and finality.