How it works
From a form to a sealed receipt in four stages, each with its assumptions stated and its status marked.
- 01
Prepare
You fill in the token. Your browser generates a fresh mint key in memory. The server stores the metadata, builds the pump.fun create_v2 transaction (with your first buy, if any) and simulates it, so the review shows the exact SOL it will cost before your wallet is involved.
- 02
Sign
The mint key signs, then your wallet does. The signed transaction goes back to the server, which refuses anything that differs by a single byte from what it prepared, then sends it to Solana.
- 03
Verify
After confirmation the server reads the transaction back from chain, decodes the create_v2 instruction itself, and checks the mint, creator, payer, name, ticker and metadata URI against the draft. Only then does the token join the board.
- 04
Seal
The launch facts are written as canonical JSON, hashed with SHA-256 and signed with ML-DSA-65. Anyone can check the receipt in the Seal Verifier, in their browser, against the chain.
| Area | Live now | Not built |
|---|---|---|
| Token launch | Wallet-signed pump.fun create_v2, optional first buy, simulated cost | Custom reserves or fee splits inside the launch |
| Receipts | SHA-256 digest, ML-DSA-65 seal, chain attestation | Verifying seals inside a Solana program |
| Exposure scan | Live Solana, Ethereum and Bitcoin lookups | Other chains; off-chain signatures |
| Reserve model | Arithmetic with pump.fun's live fee tiers | A funded treasury |
| Floor | Proportional estimate; reads a reserve wallet when configured | A redemption vault program |
| Sources | Primary documents | A live feed |
The post-quantum boundary
read thisML-DSA protects the receipts, which are a separate proof layer. It does not replace the Ed25519 signatures Solana checks on every transaction, it doesn't remove custody risk from your wallet, and it says nothing about what a token is worth. If Solana adopts post-quantum signatures, that will happen at the protocol level.