Qlyphs From first principles
Three questions, answered from the ground up. Understand these and every other page is detail.
Qlyphs is built on answers to three questions. Each answer rests on the one before it. This page reasons through them from scratch, with no prior knowledge of Quantus or tokens assumed.
Every other page follows the same method: the question first, then the reasoning, then the mechanism, then what it guarantees and where it stops.
1. Who decides who owns what?
If Alice holds 750 GLYF, what makes that true, and who could change it?
A token balance is a claim. Something has to make the claim true. There are three places it could live.
A company's database? Then the balance is whatever the operator says it is. You trust them not to edit it, lose it or freeze it.
A new feature inside the chain? Then the chain itself must change, and every token rule becomes a network upgrade.
A consequence of history everyone already agrees on. A chain already gives everyone the same ordered list of signed messages. Define precise rules for reading it, and the balance follows. No operator holds it: anyone can recompute it from the chain. This is what Qlyphs does.
- 01 / 05
A chain is an ordered list of signed messages
Strip a blockchain down and what remains is a history everyone agrees on: messages, each signed by its sender, in one order. Quantus provides exactly that. It does not need to know what a GLYF token is.
- 02 / 05
Rules turn one state into the next
Write the rules as a function: take the current state and the next message, return the new state. Valid messages change balances. Invalid ones, like spending more than you have, are rejected and change nothing.
- 03 / 05
Replay the history, get the ledger
Start from an empty state at a fixed block and apply the function to every message, in order. The result is the ledger: who holds what. No one typed a balance in; it follows from the history.
- 04 / 05
Anyone can do it, and gets the same answer
Same history, same rules, same starting point: same ledger, byte for byte. Hash it and you get a short fingerprint. Two independent programs, written in different languages, can compare fingerprints instead of trusting each other.
- 05 / 05
Change one byte and everyone can tell
Alter a single message in the history and the replay gives a different ledger, so a different fingerprint. That is why a signed fingerprint is worth checking: it pins the whole state down.
The fingerprints above are shortened and illustrative. The real ones are SHA-512 roots over the whole state.
This one idea explains most of the protocol. Messages must be byte-exact, so no two programs read them differently: see Messages. The rules must never create units from nothing: see The ledger. And everyone must start from the same block and ignore blocks that could still change: see Finality.
2. How do you pay without trusting the other side?
You send QTC, the seller sends tokens. Who goes first, and what if the other side never does?
Whoever goes first carries the risk. Pay first and the seller can keep the money. Deliver first and the buyer can keep the tokens.
An escrow moves the risk, it does not remove it. Now a middleman holds the funds, and you trust the middleman.
Make it one indivisible event instead. Quantus can execute several calls as one batch that either succeeds completely or leaves nothing behind but the network fee. Put the payment and a one-use condition in the same batch.
Let the rules deliver. Tokens were reserved for this sale before you paid. When the exact batch succeeds, the protocol moves the reserved tokens to you. No server decides to deliver.
Try it: break any step and send the batch.
- Use the one-use ticketProves this purchase is the first and only one.
- Pay the seller 10 QTCThe price, straight to the payout account.
- Pay the fee 0.1 QTC1% of the price, rounded up.
Pick a step to break, or none, then send.
The one-use condition is what stops a double payment. It can be used exactly once, so a second purchase fails at its first step, before any payment. Trade follows a full sale, Open listings shows the race between two buyers, and When things fail goes through every failure case.
3. How does a wallet know, without replaying everything?
Before paying, your wallet must know the tokens are really reserved for you. It cannot replay the whole chain. So what can it check?
It cannot trust a website's answer. A compromised server could show a reservation that does not exist.
It can check a signature. Independent replays compute the ledger and sign its fingerprint. Your wallet was built with their public keys, so a website cannot substitute its own.
Require two, built differently. One replay is written in TypeScript and one in Python. Both must sign the same fingerprint, recently, for a block that is final.
Check the exact state it pays against. The wallet finds the reservation inside the signed, finalized state and builds the purchase from it. If a single byte was changed, the check fails. Next, selective proofs (in development) send only the entry you are buying and a short path up to the signed fingerprint.
Signatures authenticate what the witnesses computed. They do not prove the witnesses are honest, which is why there are two of them, built independently, and why the wallet refuses when any check is missing. Verified by design shows the proof climbing the tree, and Why post-quantum explains why the signatures are ML-DSA-87.
The method on one page
| Question | Principle | Mechanism | Read |
|---|---|---|---|
| Who owns what? | Ownership follows from agreed history | Deterministic replay of QLYP messages | The ledger |
| When does history count? | Only what can no longer change | Pinned anchor, finalized blocks | Finality |
| How do I pay safely? | Payment and condition are one event | Atomic batch with a one-use ticket | Trade |
| What if it fails? | Two ledgers, two separate answers | Native rollback, QLYP rejection | When things fail |
| How does my wallet know? | Check signatures, not servers | Two witnesses sign the same state | Verified by design |