Docs

What ML-DSA is

ML-DSA (Module-Lattice Digital Signature Algorithm) is the signature scheme standardised by NIST in FIPS 204, August 2024. It came out of CRYSTALS-Dilithium and its security rests on the hardness of Module-LWE and Module-SIS over polynomial rings.

Unlike Ed25519, which reduces to the discrete logarithm problem, no known quantum algorithm gives more than a generic square-root style speedup against lattice problems. Shor's algorithm does not apply. That is the entire reason this scheme exists.

Parameters and sizes

This project uses ML-DSA-65 (NIST security category 3, roughly AES-192 equivalent). It is the middle parameter set: a deliberate, conservative default rather than the smallest option.

scheme        pubkey    seckey    signature   security
Ed25519         32 B      64 B         64 B     broken by Shor
ML-DSA-44     1312 B    2560 B       2420 B     NIST level 2
ML-DSA-65     1952 B    4032 B       3309 B     NIST level 3  ← used here
ML-DSA-87     2592 B    4896 B       4627 B     NIST level 5

The signature is ~52x larger than Ed25519. A Solana transaction is capped at 1232 bytes, so a 3309-byte signature cannot simply be dropped into the signature array — it has to be chunked, committed to, or verified by a program. That constraint shapes the whole roadmap.

The implementation is @noble/post-quantum, an audited, dependency-light JS implementation of FIPS 203/204/205. Nothing is hand-rolled here.

Threat model

The adversary is a future quantum computer with enough logical qubits to run Shor's algorithm on Ed25519. Two consequences matter on a public chain:

• Any address that has ever signed a transaction has published its public key. Those keys are already archived by anyone who wants them.
• Recovery is retroactive: funds sitting at an exposed address stay exposed until they move to a quantum-safe scheme.

The mitigation is to have a post-quantum key material path in place before the hardware exists, and to be able to prove control of an address with a scheme Shor cannot touch.

What we do not claim

• Solana is not currently insecure. Ed25519 is fine against classical attackers.
• This does not change Solana's consensus or validator signatures. It is an application layer on top of the chain.
• Lattice cryptography is not proven unbreakable — it is standardised and unbroken. If that changes, so does this project.
• The token does not secure anything. The cryptography works identically with or without it.

Being precise about the limits is the point. A project that overclaims about quantum resistance is indistinguishable from one that lies about it.

Verify it yourself

Copy the public key, message and signature out of the demo and check them in your own environment. Any FIPS 204 implementation will agree.

npm i @noble/post-quantum

import { ml_dsa65 } from '@noble/post-quantum/ml-dsa.js';

const hex = (s) => Uint8Array.from(s.match(/../g).map(b => parseInt(b, 16)));

const publicKey = hex('<paste public key hex>');
const signature = hex('<paste signature hex>');
const message   = new TextEncoder().encode('<paste the exact message>');

console.log(ml_dsa65.verify(signature, message, publicKey)); // true

Change one character of the message and it prints false. That asymmetry — trivially checkable, impossible to fake — is the only evidence worth offering.

Roadmap

[x] ML-DSA-65 keygen / sign / verify in the browser
[x] public docs and honest threat model
[ ] anchor a pq signature in a Solana transaction (memo commitment)
[ ] on-chain verifier program for chunked ML-DSA signatures
[ ] wallet-side helper: bind a pq key to an existing address

Each item ships with something you can click and check, or it does not ship.