Docs

Trellis has two tools and a primer. 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
   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 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.

• Nothing is 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.
• Nothing you type is sent. Messages, keys, signatures and check answers are never transmitted or logged. 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 Trellis estimates when a cryptographically relevant quantum computer will exist.