Understanding Post-Quantum Digital Signatures

The interface stays the same

From a developer's point of view, a post-quantum signature scheme exposes the same three functions as Ed25519: generate a key pair, sign bytes, verify bytes. Code that is written against an abstract signer interface can, in principle, switch algorithms by changing a configuration value.

Everything else around that interface changes: the sizes that flow through it, the time it takes, the randomness it needs and the way it fails.

Sizes, concretely

The table below lists published parameter sizes. Ed25519 is included as the baseline that Solana uses today.

• Ed25519: public key 32 B, signature 64 B.
• ML-DSA-44: public key 1,312 B, signature 2,420 B.
• ML-DSA-65: public key 1,952 B, signature 3,309 B.
• ML-DSA-87: public key 2,592 B, signature 4,627 B.
• SLH-DSA-SHA2-128s: public key 32 B, signature 7,856 B.
• SLH-DSA-SHA2-128f: public key 32 B, signature 17,088 B.

Why sizes dominate blockchain discussions

A Solana transaction is limited to 1,232 bytes in total, including all signatures, account keys and instruction data. A single ML-DSA-44 signature is nearly twice that limit on its own. The smallest SLH-DSA signature is more than six times the limit.

This means that adopting a standardised post-quantum signature at the transaction level is not a drop-in change for Solana or for most other high-throughput chains. It would require changes to transaction formats, fee models, verification cost accounting and the wallets that produce transactions. Application-level experiments, such as verifying a post-quantum signature inside a program's instruction data, face the same byte budget.

Randomness and determinism

Ed25519 signatures are deterministic: the same key and message always produce the same signature, which removes a whole class of nonce-related bugs. ML-DSA supports both a deterministic mode and a hedged mode that mixes in fresh randomness; FIPS 204 recommends the hedged mode as the default because it offers some protection against fault attacks. SLH-DSA is similar.

For developers this means signing code may need access to a secure random source, and test fixtures that compare signatures byte-for-byte must use deterministic mode explicitly.

Failure modes to design for

Hash-based schemes are stateless in SLH-DSA but there are also stateful hash-based schemes (LMS, XMSS) where reusing a one-time key is catastrophic. SLH-DSA avoids that trap at the cost of size. Lattice schemes are sensitive to implementation side channels, and pure-software implementations rarely claim constant-time execution.

None of these are reasons to avoid the schemes. They are reasons to use reviewed implementations, keep the algorithm choice behind an interface, and record which algorithm produced each signature.