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. The coin's address is derived from the throwaway identity. It also flips one byte of the signature and one byte of the certificate, and claims the wrong launch number for the address, and expects all three 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. The check asks our API 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 optional: the mint address derived from the identity (below)
The proof travels in the coin's metadata file. pump.fun's own uploader drops the block, so a signed coin's metadata file is served from this site at an address like /m/abc123, which the coin names on chain; the checker reads whatever address the chain names and trusts only the signatures inside.
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.
- The address can come from the identity too. When it does, anyone can recompute the coin's address from the proof, as set out below.
- 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.
An address derived from the identity
A launcher can let the identity choose the coin's address. The address is then a public function of the identity, a launch number and a step count, so the check "Address derived from this identity" needs nothing secret. This is the whole derivation, version hashlock/mint/v1:
idSeed = SHA-256("hashlock/identity/v1/root" || 24-word seed) bseed = SHA-256("hashlock/mint/v1/base" || idSeed) B = Ed25519 public key of bseed the base key, in the proof certified by identity leaf 10, which signs "hashlock/identity/v1/cert" 0x00 str("mint-ed25519") || 0 (u32 BE) || 10 (u32 BE) || SHA-256(B) t = SHA-512("hashlock/mint/v1/tweak" || B || i as u32 BE) read as a little-endian number, mod L address = B + ((t + j) mod L) * G i = launch number, j = steps L = 2^252 + 27742317777372353535851937790883648493, G = the Ed25519 base point
The address's private key is the base key's secret plus the same tweak. It stays in the launcher's browser and signs one thing, the coin's create transaction. The step count j moves the address one point at a time until it ends with letters the launcher picked.
The address link uses Ed25519, a curve a large quantum computer could break. Someone who did could create coins at addresses that look derived from this identity, but could not make the post-quantum identity signature beside them, so a full check still fails. Read the derived address as a convenience, and the identity signature as the proof.