Docs
How to use the Lab and the readiness check, exactly how the score is calculated, what stays on your device, and what the tools deliberately do not do. For the background cryptography, read the primer.
Overview
Lattice has two tools. The Lab generates keys and signs messages with classical Ed25519 and NIST post-quantum signature schemes in your browser, runs X25519 and ML-KEM-768 key exchange side by side, and includes a Solana Devnet panel that sends a real Ed25519-signed transaction. The Readiness check is a fourteen-question self-assessment that scores how prepared a Solana team is for a post-quantum migration.
Using the Lab
Compare classical and post-quantum signatures, and key exchange, side by side with ephemeral keys.
- Pick a scheme. Choose a card in the scheme grid. The detail strip shows the standard, public key and signature sizes relative to Ed25519, and whether a minimal one-signer transaction would fit in Solana's 1,232-byte limit. Switching scheme clears any keys and signatures.
- Generate a keypair. Generate keypair creates a fresh key in memory and records how long key generation took. The public key is shown in full; the secret key is shown truncated with its byte length. Regenerate replaces it; clear discards it.
- Sign a message. Edit the message (any UTF-8 text) and press Sign. The signature is computed over the raw UTF-8 bytes and shown in hex with its size and signing time.
- Verify, with a tamper check. Verify checks the signature against the original message and reports the result and verification time. It then verifies the same signature against the message with a single trailing space appended. That check should always fail; the chip reads
tamper check okwhen it does, andLEAKif a modified message were ever accepted.
| Scheme | Standard | Pubkey | Signature | In the Lab |
|---|---|---|---|---|
| Ed25519 | RFC 8032 | 32 B | 64 B | runs |
| ML-DSA-44 | FIPS 204 (Dilithium) | 1,312 B | 2,420 B | runs |
| ML-DSA-65 | FIPS 204 (Dilithium) | 1,952 B | 3,309 B | runs |
| ML-DSA-87 | FIPS 204 (Dilithium) | 2,592 B | 4,627 B | runs |
| SLH-DSA-SHA2-128f | FIPS 205 (SPHINCS+) | 32 B | 17,088 B | runs |
| Falcon-512 | FIPS 206 (draft) | 897 B | 666 B | size reference |
The 5 runnable schemes use the open-source @noble/curves (Ed25519) and @noble/post-quantum (ML-DSA, SLH-DSA) JavaScript libraries. The “fits 1 tx” indicator assumes one signature, one 32-byte public key and 64 bytes of message and headers, so it is a lower bound: real transactions are larger. For example, an ML-DSA-44 minimal transaction is 2,516 bytes by that formula, before even counting its 1,312-byte public key.
Timings are single measurements of one call in your browser. They are useful for comparing schemes on your own machine and are not benchmarks.
Key exchange panel. Below the signature tools, the Lab runs X25519 and ML-KEM-768 side by side with fresh in-memory keys, using @noble/curves (X25519) and @noble/post-quantum (ML-KEM). Exchange keys generates two X25519 keypairs and derives the shared secret on both sides. Encapsulate generates an ML-KEM-768 keypair, encapsulates a fresh secret to the 1,184-byte encapsulation key (producing a 1,088-byte ciphertext) and decapsulates it. Tamper ciphertext flips one random bit and decapsulates again; because of implicit rejection this returns an unrelated secret rather than an error. When both have run, a Hybrid row shows HKDF-SHA256 over the ML-KEM secret followed by the X25519 secret. That combiner is illustrative: TLS's X25519MLKEM768 concatenates the two secrets in the same order but feeds them into the TLS 1.3 key schedule instead.
The Devnet panel
Trace a real classical transaction — the path a post-quantum migration has to replace.
- Generate a Devnet keypair. Creates a new Ed25519 Solana keypair in memory and shows its address. Regenerating discards the old one; there is no way to recover it.
- Airdrop 1 SOL. Requests 1 Devnet SOL from the public Devnet faucet via
api.devnet.solana.comand waits for confirmation. Devnet SOL has no value. The faucet rate-limits by IP; if it fails, wait about 30 seconds and retry. - Sign & send to self. Builds a System Program transfer of 100 lamports from the keypair to itself, signs it with Ed25519 in the browser, submits it to Devnet and waits for confirmation. The result links to the transaction on a Devnet explorer.
- Devnet only. The panel is hard-wired to the Devnet RPC endpoint. It never connects to mainnet and never asks for a wallet.
- Ephemeral keys. The keypair lives in the tab's memory and is lost on reload. Do not send anything of value to it.
- Classical by design. The transaction is signed with Ed25519 because that is the only scheme Solana verifies for transaction signers today.
How the readiness check scores
A transparent formula. Everything below is read from the same code that scores your answers.
The check has 14 multiple-choice questions in 5 categories. Each option is worth a fixed number of points, shown next to it as +n; the lowest option in every question is worth 0. You must answer every question in a step before moving on.
| Category | Qs | Max pts | Weight | Weighted max | Share of total |
|---|---|---|---|---|---|
Signature dependencies Where your product trusts classical signatures today. | 3 | 18 | ×1.0 | 18 | 23.1% |
Key management How keys are generated, stored, rotated, and recovered. | 3 | 17 | ×0.9 | 15.3 | 19.7% |
Data at rest & harvest-now risk Exposure to adversaries that record encrypted traffic today to decrypt later. | 2 | 11 | ×0.8 | 8.8 | 11.3% |
Protocol & crypto agility How quickly you can swap a primitive without breaking users. | 3 | 17 | ×1.1 | 18.7 | 24.0% |
Migration planning Whether you have a plan — timelines, owners, test surface. | 3 | 17 | ×1.0 | 17 | 21.9% |
| Total | 14 | 80 | — | 77.8 | 100% |
- Category percent. Points earned in a category ÷ that category's maximum points, rounded. This is the per-category bar on the scorecard, and it is unweighted.
- Overall score. Each category's points are multiplied by its weight and summed, then divided by the weighted maximum (77.8) and rounded to a whole number out of 100. Because weights multiply points, a category's real influence depends on both its weight and how many points it holds; the “share of total” column shows the result.
- Band. The overall score is mapped to one of five bands using the thresholds below.
| Band | Overall score | Roughly means |
|---|---|---|
| Pre-aware | 0–19 | No meaningful preparation yet. Start with an inventory. |
| Aware | 20–39 | The risk is understood; little has been built or written down. |
| Preparing | 40–64 | Inventory and ownership exist; agility work is under way. |
| Underway | 65–84 | Abstractions, rotation and planning are largely in place. |
| PQ-ready | 85–100 | Answers are at or near the top option across the categories. |
Suggested next moves are attached to specific answer options and listed after scoring when you pick one of them. Export result downloads a JSON file with the timestamp, overall score, band, per-category breakdown and the index of the option you chose for each question. It is generated in your browser.
The band labels describe answers, not outcomes. “PQ-ready” means your self-reported practices score highly against these questions; it does not mean a product is quantum-resistant, and it cannot change the fact that Solana transaction signatures are Ed25519 today.
Privacy
- No keys persisted. Every key in the Lab and the Devnet panel is generated in your browser and held only in the page's memory. Nothing is written to local storage, cookies or a server. Reloading the page discards it.
- No telemetry on inputs. Messages you sign, keys, signatures and readiness answers are not sent anywhere or logged. The site includes no analytics or tracking scripts.
- The one network call you choose. The Devnet panel talks to the public Solana Devnet RPC to request an airdrop, read the balance and submit the transaction. That necessarily sends the ephemeral public key and the signed Devnet transaction, which become public on Devnet like any other transaction.
- Ordinary hosting logs. Like any website, the host may keep standard request logs (such as IP address and the page requested). Those do not contain anything you type into the tools.
Limitations
- Educational, not production cryptography. The Lab demonstrates sizes and behaviour. Do not use its keys or code paths to protect anything of value. Any implementation you ship needs independent review.
- Not an audit. The readiness check is self-reported and its questions are a simplification. A high score is a conversation starter, not a certification.
- No post-quantum transactions on Solana. Solana authorises transactions with Ed25519 only. Nothing here changes that, and the Devnet panel is classical by necessity.
- Approximate transaction fit. The “fits 1 tx” figure uses a simplified minimal-transaction model. Real transactions carry more accounts and instruction data.
- Browser timings. Single-shot JavaScript measurements; native implementations can be much faster.
- Devnet availability. The public faucet and RPC are rate-limited and occasionally degraded. Failures there are not failures of the Lab.
- No predictions. Nothing in Lattice estimates when a cryptographically relevant quantum computer will exist.
The only official token and deployer addresses are the ones shown in the token panel on the dashboard. Copy them from there, and treat any address posted elsewhere (replies, DMs, other sites) as unverified until it matches character for character.
These docs are about the tools. Nothing on this page, in the primer or in the tools is financial advice.
View official addressesFAQ
Does Lattice make my wallet or program quantum-resistant?
Can I import my own wallet or seed phrase into the Lab?
Why can't the Devnet panel send a post-quantum transaction?
Why does Falcon show as “coming soon”?
Why are my timings different from someone else's?
Is my readiness score saved anywhere?
Is there a date by which we must migrate?
Is the readiness check an audit or certification?
Still have a question? The primer covers the cryptography behind every number on this page, chapter by chapter, with the standards it cites.