§00Post-quantum readiness for Solana builders
Your keys rest on a math assumption. Check it before it changes.
Every Solana account is an Ed25519 key. Lattice is a primer, a readiness check and a lab for builders who want to know, in bytes and milliseconds, what a move to ML-DSA and ML-KEM would cost them. Devnet only. Not an audit.
Measure first. Migrate on purpose.
| Scheme | Pubkey | Signature | Fits 1 tx |
|---|---|---|---|
| Ed25519classical | 32 B | 64 B | yes |
| ML-DSA-44post-quantum | 1.31 kB | 2.42 kB | 2.0× over |
| ML-DSA-65post-quantum | 1.95 kB | 3.31 kB | 2.7× over |
| SLH-DSA-128fpost-quantum | 32 B | 17.1 kB | 13.9× over |
Sizes are published parameters (FIPS 186-5, FIPS 204, FIPS 205), not measurements. Fit assumes one signer, one public key and a minimal message.
§01Threat ledger
Three facts, no adjectives.
- NowHarvest now, decrypt later
Signatures and public keys are already on-chain and public. Anything recorded today is available to whatever machine exists later. The exposure is not in the future; the capability is.
- No dateA cryptographically relevant quantum computer
Nobody credible has a date. NIST finalised ML-DSA, SLH-DSA and ML-KEM in 2024 anyway, because migrations take longer than forecasts.
- 2.0×ML-DSA-44 signature vs. the Solana transaction limit
A 2,420-byte signature does not fit in a 1,232-byte transaction. Any migration starts with a transaction-format question, not an algorithm question.
Sheet 02 · Transaction budget
Pick a scheme and a number of signers. The bar is one Solana transaction.
Limit 1,232 B
Illustrative. Sizes are published parameters; the base estimate assumes one small instruction. Solana has no native post-quantum verifier today, so these transactions could not be submitted regardless of size.
§02Migration path
Migration is a programme, not a library swap.
Replacing an algorithm in code is an afternoon. Replacing it under live users, keys and partners is the work. Click a step.
The readiness check walks the list with you.
Scoring is transparent and self-reported.
The lab, with ephemeral demo keys only.
Primer chapters on hybrid schemes and agility.
Docs and migration checklists.
§03Three surfaces
Read it, score it, measure it.
Read the primer
Short chapters, each with the standard it cites, a review date and a list of what it does not cover. Shor and Grover, Ed25519 vs ML-DSA, ML-KEM in hybrid mode, Solana transaction authorisation, and crypto-agility with a migration plan.
Open the primer§04Who it is for
Built for the people who hold the keys.
- 01
Wallet and custody teams
Key generation, storage, recovery and signing under a future scheme change.
- 02
Solana program developers
Authorities, PDAs and session keys that assume Ed25519 today.
- 03
Protocol and validator teams
Transaction size, verification cost and fee accounting for larger signatures.
- 04
Security researchers
Reference numbers, labelled implementations and a place to compare schemes.
- 05
Students
A primer that names the standard, cites the source and says what it leaves out.
- 06
Teams who were asked by their investors
A ranked list of exposures you can put in a deck without lying.
§05What we do not claim
Honest about the edges.
Not a certification.
The readiness check is self-reported. The output is a ranked list of things to look at, and the scoring is shown next to every answer.
Does not make anything quantum-resistant.
Nothing on Lattice changes the security of a wallet, a program or a chain. It helps you measure and plan.
Prototypes are not production code.
The lab uses labelled, pure-JavaScript implementations for demonstration. Anything you ship needs independent review.
Devnet only.
Any on-chain experiment runs against Solana Devnet. No post-quantum signature created here is ever submitted to mainnet.
§07Ship log
What shipped, dated.
Lattice is live: landing, primer, readiness check and lab, with X25519 vs ML-KEM-768 key exchange.
Brand kit v1: Blueprint palette, Fraunces / Inter / JetBrains Mono, lattice mark.
Project kicked off: primer, readiness check and lab specified.