Choosing ML-DSA
Frost’s account signatures are ML-DSA, the lattice-based scheme standardised by NIST as FIPS 204.
Why a standardised scheme
Section titled “Why a standardised scheme”Post-quantum cryptography has a long history of schemes that looked strong and were later broken — sometimes spectacularly, sometimes years into standardisation. That history argues for conservatism: use what has survived the most scrutiny, and prefer a published standard over a better-looking research result.
FIPS 204 is a finalised NIST standard with a long public analysis history, a NIST validation programme (ACVP) with published test vectors, and multiple independent implementations. For a chain whose entire premise is quantum-resistance, being on the standard is worth more than being on the smallest or the fastest.
Standardisation also buys something concrete: interoperability. Because the verifier precompiles implement plain FIPS 204 with no local modifications, any conformant signer works — Apple’s CryptoKit, PQ-capable HSMs, and every software library. There is no Frost signature format for a hardware vendor to implement.
Why ML-DSA rather than a hash-based scheme
Section titled “Why ML-DSA rather than a hash-based scheme”Hash-based signatures (SLH-DSA, the FIPS 205 standard) rest on weaker assumptions — essentially just the security of a hash function — which makes them the most conservative choice available. Their drawback is size and speed: SLH-DSA signatures are far larger than ML-DSA’s already-large ones, and slower to verify.
For account signatures, where every transaction carries one and calldata gas dominates the cost, that is prohibitive. So Frost uses lattice signatures for the high-volume path.
It does not rely on lattices alone everywhere. The consensus layer’s long-lived checkpoint root keys are signed with both ML-DSA-65 and SLH-DSA-SHA2-192s, and both must verify — so a cryptanalytic break in the lattice family does not break the chain’s certified history. See Two-tier consensus keys. The reasoning is that the places where you can afford a large, slow, maximally-conservative signature are exactly the places where you should use one.
Why ML-DSA-65 for the default account
Section titled “Why ML-DSA-65 for the default account”Frost provides verifiers for two parameter sets:
| ML-DSA-44 | ML-DSA-65 | |
|---|---|---|
| Public key | 1,312 B | 1,952 B |
| Signature | 2,420 B | 3,309 B |
| Verifier gas | 10,500 | 16,000 |
| Apple Secure Enclave | No | Yes |
ML-DSA-44 is cheaper on every axis. The rotatable v2 account — the one users are told to use — nevertheless uses ML-DSA-65, for one reason: Apple’s CryptoKit supports ML-DSA-65 and ML-DSA-87, and not ML-DSA-44.
Choosing the cheaper parameter set for the default account would have made hardware custody impossible on the most widely deployed secure element in the world. A key that lives in a Secure Enclave cannot be extracted, copied, or phished; a key in a file can be all three. That is worth more than the roughly 5,500 gas and 900 bytes the cheaper set would save.
This is not theoretical. A signature produced inside a physical Secure Enclave
verifies against the 0x14 precompile bit-for-bit, and golden vectors captured
from a real device are part of the execution layer’s test suite.
ML-DSA-44 remains available at 0x15
for accounts where gas is the binding constraint and hardware custody is not
required.
What the precompiles do and do not do
Section titled “What the precompiles do and do not do”The verifiers implement pure ML-DSA with an empty context string — not the pre-hash (HashML-DSA) variant, and not a Frost-specific profile. Public keys and signatures use the standard FIPS 204 encodings.
They also return a value in every case. Wrong-length input, a non-canonical public key, and an invalid signature all return the 32-byte zero word — never empty data, never an error. A verifier that can return empty on malformed input invites a caller to read “no output” as “verified”, which is the difference between an account that checks a signature and an account anyone can spend from.
What this costs
Section titled “What this costs”Size. A spend witness is 3,309 bytes against ECDSA’s 65. Calldata gas on that witness, not the verification, is the dominant cost of a post-quantum transaction — and it is why witness segregation and history tiering exist at all.
No aggregation. ML-DSA signatures do not aggregate the way BLS signatures do. Many signatures are simply many signatures.
No public-key recovery. This is the property that rules out a post-quantum EOA and forces the smart-account model. See Keys in accounts, not a registry.
Assurance
Section titled “Assurance”Correctness of a verifier is not something to take on trust, so the implementation is checked three ways:
- against NIST ACVP signature-verification vectors,
- differentially against an independent implementation in another language, including structured mutation fuzzing,
- against golden vectors from Apple CryptoKit, both a software key and a key generated inside a real Secure Enclave.
The third is the one that proves interoperability rather than merely self-consistency.