Docs

Kyberpad is a pump.fun launchpad and a set of readiness tools. Every coin launched here binds the dev's Solana wallet to an ML-DSA-65 (FIPS 204) key made in their browser, records the mint's authorities right after launch, and starts a chain of receipts sealed with Kyberpad's own ML-DSA-65 key. The scan reads the same authority facts for any mint on Solana.

The tools are a primer and two more. The lab creates throwaway keys in your browser, signs and verifies with Ed25519 and the NIST post-quantum signatures, runs X25519 and ML-KEM-768 side by side, and includes a Devnet panel that sends a real Ed25519-signed Solana transaction. The readiness check is a 15-question self-assessment that scores how prepared a Solana team is to change its cryptography.

1. 1
   Describe the coin. Name, ticker, logo, description, links and an optional dev buy. The metadata JSON and image are served from this site, and their SHA-256 hashes go into the launch receipt.
2. 2
   Generate the post-quantum key. With your wallet connected, your browser makes a fresh ML-DSA-65 key pair from a 32-byte random seed, and a fresh mint key. The PQ key signs a binding that names your wallet and that mint. You must download the key file (it holds the seed) before you can continue. It is the only copy.
3. 3
   Review and sign. The server checks the binding signature, builds a pump.fun create_v2 transaction (plus buy, if any) with a memo instruction carrying kyberpad:bind:v1:<digest>, and simulates it. Your browser recomputes the digest and refuses to continue if the server's differs. The mint key signs in the tab, your wallet signs as creator and fee payer.
4. 4
   Confirm and seal. After confirmation the server reads the transaction back from chain and checks it: a successful create_v2 for the drafted mint, name and ticker, with your wallet as creator, payer and signer of the memo. It then reads the mint's authorities and seals receipt #1. Anyone can trigger this check again with the signature; it is idempotent.

Kyberpad never holds your wallet key, the mint key or the PQ seed. The launch costs what pump.fun charges plus network fees and rent; the review screen shows the simulated total.

The binding body is canonical JSON (sorted keys, no whitespace):

{
  "type": "kyberpad.binding", "version": 1,
  "network": "solana:mainnet",
  "mint": "<new mint>", "creator": "<dev wallet>",
  "alg": "ML-DSA-65",
  "keyId": "<first 16 hex of SHA-256(public key)>",
  "publicKeySha256": "<SHA-256 of the 1,952-byte key>"
}

• Post-quantum half. The ML-DSA-65 key signs the canonical body with FIPS 204 context kyberpad/binding/v1, a 3,309-byte signature. It names the wallet, so the PQ key vouches for the wallet.
• Classical half. SHA-256 of the body is the digest. The dev wallet signs the transaction that contains the memo kyberpad:bind:v1:<digest> as a required signer of that memo instruction, so the wallet vouches for the PQ key.
• Why both. Today the wallet signature is what Solana checks. If Ed25519 keys ever become recoverable from public keys, the on-chain memo still dates the binding to the launch slot, and only the holder of the ML-DSA-65 seed can keep producing valid signatures for the coin.
• Size on chain. Only the 81-byte memo goes on chain. The 1,952-byte public key and the signature are kept in the launch receipt, whose digest is sealed.

Receipts are canonical JSON with type: kyberpad.receipt, a per-coin seq and the digest of the previous receipt in prev, so the chain can't be reordered or trimmed without breaking. Kyberpad seals each one with its ML-DSA-65 key under context kyberpad/receipt/v1. The public key is at /api/seal. The launch receipt holds the whole binding, the metadata and image hashes, the dev buy, and the mint's authority slots read from chain.

On a coin page, the dev loads their key file (read in the tab, never uploaded), writes up to 500 characters and signs. The note body names the network, the mint, the receipt slot it will take, the text and the signing time, and is signed with context kyberpad/note/v1. The server accepts it only if the signature verifies against the coin's bound key, the slot is the next free one and the time is within ten minutes of its clock. Then it seals the note as the next receipt.

• Replays fail. A note names its slot, so the same signed note can't be posted twice or into another coin.
• Impostors fail. A signature from any other key, including another Kyberpad coin's key, is refused.
• Use it for. New social accounts, migrations, fee plans, warnings about fake accounts. Anything holders need to know really came from the dev.

The scan fetches the mint with getAccountInfo (jsonParsed) and lists the mint and freeze authorities, then every Token-2022 extension field that holds an authority or delegate (metadata, metadata pointer, permanent delegate, transfer hook, close, fees, pause and others, including extensions added later). For classic SPL mints it also reads the Metaplex metadata account; an immutable record counts as no authority. It shows the pump.fun bonding curve and any Kyberpad binding.

Grades. Nothing to steal means every slot is empty. Otherwise the scan counts the live keys and says what each could do. A live authority isn't a flaw today, and stablecoins need theirs, but each one is an Ed25519 public key on chain, which is exactly what Shor's algorithm attacks.

1. 1
   Choose a scheme. Click a card. The strip below it shows the standard, the key and signature sizes against Ed25519, and the size of the smallest transfer if that scheme signed it. Switching scheme throws away any keys and signatures.
2. 2
   Generate a keypair. Creates a key in memory and records how long that took. The public key is shown in full. The secret key is shown only as its first and last bytes and its length. New keypair replaces it and discard drops it.
3. 3
   Sign. Edit the message and press Sign. The scheme signs the exact UTF-8 bytes; the signature appears in hex with its size and signing time.
4. 4
   Verify, and try to cheat. Verify checks the signature against the signed message and times it. It then checks the same signature against the message with one character added. That second check must fail; the chip reads edited message rejected when it does, and turns red if an edited message were ever accepted.

The runnable schemes use the open-source @noble/curves (Ed25519, X25519) and @noble/post-quantum (ML-DSA, SLH-DSA, ML-KEM) libraries, which have been independently audited.

The smallest-transfer figure. The lab starts from a real 183-byte Ed25519 transfer to self (the transaction the Devnet panel sends), swaps in the scheme's signature, and adds its public key minus 32 bytes, because a 32-byte address cannot double as a larger verification key. The result is compared with Solana's 1,232-byte legacy cap and the 4,096-byte v1 cap. It is a floor: real transactions carry more accounts and data.

Key exchange. Exchange keys creates X25519 keypairs for Alice and Bob and derives the shared secret on both sides. Encapsulate creates an ML-KEM-768 keypair, wraps a fresh secret to the 1,184-byte encapsulation key (giving a 1,088-byte ciphertext) and unwraps it. Tamper ciphertext flips one random bit and unwraps again; because of implicit rejection the result is an unrelated secret, not an error. Once both have run, the hybrid box shows HKDF-SHA256 over the ML-KEM secret followed by the X25519 secret. TLS uses the same order but its own key schedule, so treat the hybrid box as an illustration.

Timings are single runs in your browser. Use them to compare schemes on one machine; they are not benchmarks.

1. 1
   Create a Devnet keypair. Makes a new Ed25519 Solana keypair in memory and shows its address. A new key discards the old one for good.
2. 2
   Verify on Devnet, no SOL needed. Signs the 183-byte transfer to self and asks a Devnet validator to simulate it with signature checking on. The validator verifies the Ed25519 signature, then stops because the key holds no SOL (AccountNotFound). A copy with one signature bit flipped is checked too and must come back SignatureFailure. Nothing is sent or stored on chain.
3. 3
   Get Devnet SOL. The site's own Devnet faucet sends the key 0.002 SOL, enough for hundreds of transfers, and waits for confirmation. If that faucet is empty, the request falls back to the public Devnet faucet. Devnet SOL has no value. Each key is funded once.
4. 4
   Send 100 lamports to self. Builds a System Program transfer from the keypair to itself, signs it in the browser, submits it to Devnet and waits for confirmation. You get an explorer link, the exact size in bytes, and the size the same transfer would be with ML-DSA-44.

• Devnet only. Requests go through this site's small server proxy, which only forwards a short list of read, send and status calls to a Devnet RPC. The panel never touches mainnet and never asks for a wallet.
• Throwaway keys. The keypair lives in tab memory and disappears on reload. Don't send anything of value to it.
• Classical on purpose. It signs with Ed25519 because that is the only scheme Solana verifies for transaction signers today.

There are 15 multiple-choice questions in 5 areas. Each option is worth a fixed number of points, shown next to it as +n, and the weakest option in each question is worth 0. Every question in a step must be answered before moving on.

1. 1
   Area percent. Points earned in an area divided by that area's maximum, rounded. This is the bar on each area card, and it is not weighted.
2. 2
   Overall score. Each area's points are multiplied by its weight and summed, divided by the weighted maximum (85.2) and rounded to a whole number out of 100. An area's real influence depends on both its weight and its point total; the share column shows the combined effect.
3. 3
   Band. The overall score maps to one of five bands.

Next moves are attached to particular answer options and listed after scoring for each one you picked. Export JSON downloads the timestamp, score, band, per-area breakdown, the option you picked for each question and the next moves. The file is generated in your browser.

Bands describe answers, not outcomes. “Swap-ready” means your self-reported practice scores well against these questions. It does not mean a product is quantum-resistant, and it does not change the fact that Solana transaction signatures are Ed25519 today.

• Launch keys stay with you. Your wallet signs in your wallet. The mint key and the ML-DSA-65 seed are made in the tab; the seed leaves only as the key file you download. The server receives the PQ public key and its signature, which become part of the public receipt.
• Lab keys are never stored. Every key in the lab and the Devnet panel is created in your browser and held only in page memory: no local storage, no cookies, no server. A reload wipes it.
• Lab and check inputs are never sent. Lab messages, keys, signatures and check answers are never transmitted or logged. Launch fields and notes are sent because they become public. The site loads no analytics or tracking scripts.
• The one network call you trigger. The Devnet panel sends the throwaway public key and, when you press send, the signed Devnet transaction to this site's proxy, which passes them to a Devnet RPC to fund the key, read its balance and submit the transaction. Both become public on Devnet like any other. The proxy logs nothing; the secret key never leaves your browser.
• Ordinary hosting logs. Like any website, the host may keep standard request logs such as IP address and page. They contain nothing you type into the tools.

• For learning, not production. The lab demonstrates sizes and behaviour. Don't use its keys or code to protect anything of value; whatever you ship needs its own review.
• Not an audit. The readiness check is self-reported and its questions simplify a complex topic. A high score opens a conversation, it does not certify anything.
• No post-quantum transactions on Solana. Solana accepts only Ed25519 transaction signers today. The Devnet panel is classical because it has to be.
• A floor, not a forecast. The smallest-transfer figure uses a minimal one-signer transfer. Real transactions are larger.
• Browser timings. Single runs of JavaScript. Native implementations are much faster.
• Devnet can be flaky. Devnet is a test network and is sometimes slow, and the site faucet can run dry between top-ups. Failures there are not failures of the lab.
• No predictions. Nothing on Kyberpad estimates when a cryptographically relevant quantum computer will exist.