Identity signatures
A launcher can sign a coin with a post-quantum key, so anyone can check that two coins came from the same hands. Ten schemes are on offer. Each one below runs in your browser, on a key made on this page and thrown away.
Identity signature
Proves who launched a coin. It sits in the coin's metadata and is checked in your browser. Any of the schemes on this page can do it, because a browser has room for large keys and slow math.
Vault lock
Decides who can move money. It is a hash-based signature that the Solana program checks on chain, on every withdrawal. Only a hash-based signature fits inside a Solana transaction's compute limit today.
Those are different jobs. Identity signatures prove who launched a coin and are checked in your browser. The vault's lock is a hash-based signature checked on chain. A coin with a valid identity signature can still have unprotected fees, and a sealed coin needs no identity signature at all: to see where the money goes, use Verify.
iThe schemes
Sizes are exact, in bytes. The bars are drawn to one scale, so you can see what each choice adds to a coin's metadata.
| Scheme | Standard | Family | Signature and public key | What it proves |
|---|---|---|---|---|
| Loading the scheme list... | ||||
Not offered
iiTry it
Each run makes a throwaway key from fresh random bytes, signs the message below, checks the signature, then builds a full identity proof for a made-up coin and checks that too. It also flips one byte of the signature and one byte of the certificate, and expects both to be refused. Nothing leaves this page.
Times are for this device, one run each, in a background thread. The demo identity tree has 256 leaves so it builds fast; a launcher's has 1,024.
iiiVerify a coin's identity proof
Paste a mint and this page reads the coin's metadata address from the Solana RPC you choose, fetches the metadata file from wherever the launcher put it, and checks the proof inside. Or paste a proof directly. Our server is asked for nothing.
ivHow a proof is put together
The launcher's 24 words grow a second tree of one-time keys, the identity tree. It is separate from the vault's spending tree, so signing a launch never uses up a vault key. The root of that tree is the identity.
24 words |-- vault tree guards money, checked on chain (not used here) '-- identity tree root = the identity '-- one leaf signs SHA-256(scheme public key) the certificate '-- that key signs the launch message the signature launch message = network, mint, name, symbol, creator, scheme, identity root, time
A checker rebuilds the message from the coin's own details, checks the scheme's signature, checks that one leaf signed the hash of the scheme's key, and walks that leaf's path up to the identity root. With WOTS+ Merkle there is no second key: a leaf signs the launch itself.
- The mint is inside the message, so a proof copied onto another coin fails.
- Each leaf has one fixed job. The leaf that certifies a key can only ever sign that key's hash, so a lost counter cannot make it sign two things. WOTS+ Merkle is the exception: it spends one leaf per launch and needs a counter.
- A pass names an identity, not a person. Anyone can make an identity. What you compare is the fingerprint, across a launcher's coins or against what they published.
- The code. WOTS+ is the vault program's own client at /pq/client. The other schemes are noble-post-quantum 0.7.1, pinned and unmodified apart from import paths. Its author has reviewed it; no outside firm has audited it yet, and it does not claim constant-time signing. Every scheme passes its published test vectors: node scripts/qa/sig-kat.mjs.