ML-DSA-44

POST-QUANTUM · SOLANA FORK · 2026

making the Solana validator quantum-secure — payments and consensus votes signed with NIST's post-quantum standard, proven live on-chain

fig. 1 — a quantum attack on each scheme's foundationEd25519: solved · ML-DSA-44: hard

ED25519discrete logrecovering…

ML-DSA-44module latticeshortest vector: hard

01THE GOALquantum-resistant by design

A large enough quantum computer forges Ed25519 — and Solana signs everything with it. This fork makes the validator quantum-secure, replacing its signatures with ML-DSA-44, the scheme NIST standardized as FIPS 204.

And it isn't on paper. On a live validator, a SOL transfer signed with a post-quantum key confirms on-chain, and the validator's own consensus votes are signed with ML-DSA-44 — the chain produces, confirms, and finalizes on them. Its payments, consensus votes, and on-chain verification are all quantum-secure. It runs on a self-hosted fork, not live-Solana-compatible by design, but the post-quantum signing it proves is real and end-to-end.

02WHAT'S QUANTUM-SECUREverification, payments, and votes — all live

The validator signs several things through one shared engine. This fork hardens the three that carry value and consensus — on-chain verification, user payments, and the validator's own votes — all live on ML-DSA-44 and verified end to end.

PRECOMPILE

apps verify a post-quantum signature on-chain

fips204 · ✓ live

↓

PAYMENTS

the fee payer's key and address are post-quantum

ML-DSA tx · ✓ live

↓

VOTES

the validator's consensus votes are post-quantum; the chain finalizes

consensus · ✓ live

STACK — Rust · forked solana-labs/solana v2.0.0 · fips204 0.4.6 (FIPS 204) · WSL2 · solana-test-validator

03WHAT IT PROVESEd25519 → ML-DSA-44

FIPS 204

NIST post-quantum standard, implemented

signing surfaces quantum-secured

LIVE

payments + votes confirm and finalize

~40×

larger signatures, absorbed end-to-end

04WHAT IT TOOKa signature built for a system that assumed tiny ones

Putting a signature ~38× the size of Ed25519's through a validator built for tiny ones meant unwinding assumptions baked in deep — each solved so the post-quantum path runs beside the original:

address from key

an account's address was literally its 32-byte key; ML-DSA's is 1312 — so the address became sha256(pubkey), with the full key carried inside the tx

room on the wire

a whole tx had to fit ~1232 bytes; the packet ceiling was raised to 8192 so a post-quantum signature fits, with every dependent assert moved in step

drop-in, not a cutover

a 0x00 lead byte marks a post-quantum tx so it runs beside Ed25519 — the chain gains quantum-secure signing with no risky hard switch, and never stops producing blocks

05VERIFIED LIVEplates 01–02 · real keys · real signatures · raw JSON-RPC

# Payments — a SOL transfer signed post-quantum confirms on-chain
$ bash programs/ml-dsa-tests/demo-transfer.sh
  ML-DSA-44 transfer confirmed         forged transfer rejected

# Votes — the validator's own consensus votes are post-quantum
$ solana-test-validator --ml-dsa-vote /tmp/mldsa-vote.bin
  chain confirms + finalizes on ML-DSA-44 votes

# Precompile — apps verify a post-quantum signature on-chain
$ bash programs/ml-dsa-tests/demo.sh
  valid ML-DSA-44 signature accepted   tampered one rejected

[ 0x00 ]                       marks a post-quantum tx
[ sig count ][ 2420-B ML-DSA-44 signatures ]
[ key count ][ 1312-B signer public keys   ]
[ bincode(Message) ]

address = sha256(public_key)             // 32 B — accounts-db unchanged
verify  = ML-DSA(sig) && sha256(key) == account_keys[i]

[next study — InsidePoly→]