Post-Quantum Cryptography

Every signature ever written to this chain is post-quantum. Here's the NIST standard behind it, the alternatives we ruled out, and what it actually costs.

TL;DR. Aevum implements ML-DSA-65 (Dilithium3), the NIST-standardized post-quantum signature scheme, for all transaction and consensus signatures — quantum-safe from genesis, with no migration phase and no classical signatures in the history.

Aevum implements ML-DSA-65 (Dilithium3), a NIST-standardized post-quantum digital signature scheme, for every transaction and consensus signature. Every signature ever written to the chain is quantum-safe from genesis — no migration phase, no classical signatures in the history, no cryptographic upgrade planned for later.

Why post-quantum matters

Modern blockchains sign with elliptic-curve schemes whose security rests on the discrete-log problem being hard. A quantum computer running Shor's algorithm doesn't weaken ECDSA — it breaks it completely.

The sharper problem is "harvest now, decrypt later." Blockchains keep a permanent public ledger, so an adversary can archive chain history today and unlock it the moment quantum computers catch up. The integrity of the chain's history is broken, not just its future.

Estimates for when a cryptographically relevant quantum computer arrives range from 10 to 25 years out, with real uncertainty either way. What isn't uncertain: NIST standardized a post-quantum signature scheme in August 2024, so migrating today is a choice, not a blocker.

What we picked: ML-DSA-65

NIST published FIPS 204 in August 2024, standardizing the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), descended from CRYSTALS-Dilithium. There are three security levels:

Aevum uses ML-DSA-65 — the middle option, the typical sweet spot between signature size and security margin. Dilithium's security rests on Module Learning With Errors and Module Short Integer Solution, not discrete logarithms. All of it is integer arithmetic: no floating point, no curve operations.

Alternatives considered

Falcon-512 produces signatures roughly five times smaller (~666 bytes), but needs constant-time floating-point arithmetic — a real risk to implement correctly across JavaScript and WASM.

SLH-DSA (SPHINCS+) is hash-based and conservative, but its 8–17KB signatures would put megabytes of signature data into every finalized block across a validator committee.

Hybrid classical-plus-post-quantum schemes were considered and dropped for v1 — they roughly double signature size and complexity for marginal benefit once you've already committed to a NIST-standardized PQC scheme.

Cost analysis

Post-quantum signatures aren't free. Measured against Ed25519:

Aevum absorbs this with a bounded ~100-validator committee, no signature aggregation in v1, public-key reuse for repeat senders, and a verification-first design — contract execution itself doesn't touch PQC directly.

Implementation details

Addresses derive directly from the public key:

That's a 20-byte hex address with an EIP-55-style mixed-case checksum. Transactions carry the sender's public key (~1.9KB) or a reference to it, plus a ~3.3KB signature. Validators sign both pre-vote and pre-commit messages, which works out to roughly 330KB of consensus signature data per block.

The implementation leans on PQClean, the canonical C implementation of the NIST standards, compiled to WASM and to native Node addons. The protocol spec pins an exact PQClean commit hash — updating it is a hard fork, on purpose.

Open questions

• No standardized BIP-32 equivalent exists yet for Dilithium HD wallet derivation
• Multi-signature scheme choice is still open
• Threshold signatures are active research, not shipped
• Long-term migration mechanics, despite Dilithium being the right pick today