Post-quantum accounts

The home page makes four claims about Frost accounts in two sentences: they verify ML-DSA signatures, through native precompiles, at a price comparable to a handful of ECDSA recoveries, with no registry and no bundler holding an ECDSA key on the critical path. This page takes each claim in turn, with the numbers.

ML-DSA

ML-DSA — the Module-Lattice-Based Digital Signature Algorithm — is the signature scheme NIST standardised as FIPS 204 in August 2024. It is the standardised form of CRYSTALS-Dilithium, the primary signature selection of NIST’s post-quantum competition, and its security rests on structured lattice problems (Module-LWE and Module-SIS) for which no efficient quantum algorithm is known. Shor’s algorithm, which breaks ECDSA, does not apply.

The standard defines three parameter sets. Frost verifies two of them.

	ML-DSA-44	ML-DSA-65	ML-DSA-87	secp256k1 ECDSA
NIST security category	2	3	5	—
Public key	1,312 B	1,952 B	2,592 B	33 B
Signature	2,420 B	3,309 B	4,627 B	65 B
Frost verifier	`0x15`	`0x14`	—	`0x01`

A signature is roughly fifty times the size of an ECDSA signature. That number matters, but two other properties of the scheme shape the chain more:

There is no public-key recovery. ecrecover reconstructs the signer’s public key from the signature and the message, which is why Ethereum never stores or transmits public keys and why an address can be a 20-byte hash of one. ML-DSA has no such operation. The verifier must be handed the public key, so something on chain has to hold it.

The key does not fit in an address. A 1,952-byte key cannot be derived from 20 bytes. Whatever holds the key, the address can only be a commitment to it.

The Frost precompiles implement pure ML-DSA with an empty context string, as FIPS 204 specifies — not the pre-hash variant, and not a local profile — so any conformant signer works. That includes Apple’s CryptoKit, which is how a key that never leaves a Secure Enclave can sign a Frost transaction; see Hardware custody. Choosing ML-DSA explains why ML-DSA-65 is the default parameter set and why hash-based SLH-DSA is reserved for consensus checkpoint roots rather than accounts.

Further reading: the FIPS 204 standard itself, and NIST’s post-quantum cryptography project.

What a signature costs

Verification is native. Both verifiers are priced at throughput parity with ecrecover: measured on validator-class hardware, an ML-DSA-65 verification takes about 5.3 times as long as an ECDSA recovery, so it costs about 5.3 times the gas.

Precompile	Address	Gas	Measured verify time
`ecrecover`	`0x01`	3,000	33.7 µs
VERIFY_MLDSA44	`0x15`	10,500	116.3 µs
VERIFY_MLDSA65	`0x14`	16,000	177.7 µs

The price is flat, because the inputs are fixed length — exactly 5,293 bytes for ML-DSA-65 and 3,764 for ML-DSA-44 — and it is charged in full whether or not the signature verifies. Pricing the verifiers has the derivation and explains why these two numbers are consensus-critical.

The verification, though, is not where the money goes. Frame-transaction calldata is charged under EIP-7623 rules, and a post-quantum witness — random, incompressible bytes — pays the full non-zero-byte rate of 40 gas per byte. The witness alone therefore costs about:

Account	Witness	Calldata gas on the witness
ML-DSA-44	2,420 B	≈ 96,800
ML-DSA-65	3,309 B	≈ 132,360

Here is a real one. This is a plain transfer from a fixed-key ML-DSA-65 account (code ID 0x02) in block 132,306 of the live chain (transaction 0x9ffe3de5…ea5fbb):

Component	Gas
Intrinsic: 15,000 + 2 frames × 475	15,950
Calldata, almost all of it the 3,309-byte witness	134,480
VERIFY frame, of which 16,000 is the precompile call	17,526
SENDER frame — the transfer itself	2,625
Total	170,581

A plain transfer on Ethereum costs 21,000 gas. A post-quantum transfer costs about eight times that, and almost 80% of it is the bytes. The same transfer from an ML-DSA-44 account in the same block used 129,206. This ratio — bytes over arithmetic — is why the chain stores witness bytes separately from the transactions that carry them and prunes them once finality has made them redundant. See Witness segregation, and the gas accounting in the transaction reference for the exact formula.

Where the key lives: a registry, or the account

Since the verifier must be handed the key, and the key cannot be derived from the address, a post-quantum chain has to decide where keys live. There are two structural answers.

A registry

A protocol-level registry maps each address to a post-quantum public key and a scheme identifier. Before an account can transact post-quantum, its owner registers a key in a transaction; from then on the verifier looks the key up.

Circle’s Arc is taking this route. Arc mainnet verifies SLH-DSA-SHA2-128s signatures through a precompile today, and Circle’s post-quantum whitepaper (§3.4.4) describes an on-chain public-key registry that binds an existing account address to a post-quantum public key and its scheme, with the binding authorised by the address’s existing ECDSA key. The design is sound provided every registration lands before a cryptographically relevant quantum computer exists. Native post-quantum transaction signing is a later milestone on Arc’s roadmap, and Arc’s own documentation expects it to take the form of EIP-8141 frame transactions once the EIP is final. Ethereum researchers are exploring a similar registry for validator keys.

A registry is a coherent design with real advantages. Existing addresses keep their address: a user upgrades in place rather than moving funds. One copy per key: the registry amortises the 1–2 KB of key material across every use. And the account model stays exactly what wallets already understand.

It also has costs, and they are the reason Frost does not use one.

Registration is a transaction. It needs gas, so a new user cannot receive funds safely at a post-quantum address until they have already transacted — which needs funds. And in the Arc design the registration is signed with the ECDSA key being retired, so the root of trust for every binding is a classical key, and the deadline for using it is one nobody can see.
Shared, consensus-critical state. Every verification path depends on one contract, which makes it a hot spot, a governance surface, and a single point of failure.
The algorithm list is baked in. A registry’s format enumerates the schemes it supports. Adding one is a protocol change.

The account itself

Frost puts the key in the account. Every post-quantum account is a small contract that holds its own public key and verifies its own signatures, and the account’s address is a CREATE2 commitment to that key material:

address = keccak256(0xff ‖ FACTORY ‖ salt ‖ keccak256(initcode))[12:]

where the init code contains the key. The binding between address and key is established by arithmetic, offline, the instant a key exists. Nothing is registered because nothing is shared.

No pre-registration. A wallet shows a receiving address the moment it generates a key. Funds can arrive before the account exists on chain, and the account’s first outgoing transaction deploys it, paid for out of the balance already sitting there. See Counterfactual onboarding.
No shared bottleneck. An account’s security depends on its own code and its own key, and on nothing else.
Per-account policy. Because the account is a contract, it can hold two keys, rotate them, or apply any rule it likes. The default rotatable account keeps an active key and a hash commitment to a backup key, so a lost device is survivable and a compromised active key can still not lock the owner out. See Accounts and keys.
Crypto-agility is structural. A new scheme is a new precompile and a new account type. It does not change what an address means, and nobody has to migrate on anyone else’s schedule.

The costs are the mirror image of the registry’s. An existing classical address cannot be upgraded in place — a post-quantum account is a new address, so adopting one means moving funds. And every account carries its own copy of a 1,952-byte key. For a chain built post-quantum from genesis the first cost does not arise; the second is real, and it is one reason storage gets first-class attention in the design. (Frost also ships a hash-commit account that stores only the key’s hash and takes the key as a witness on each spend — the same fingerprint idea Arc’s whitepaper describes for smart accounts — as a cheaper-to-deploy option for accounts that transact rarely.)

Keys in accounts, not a registry makes the argument in full.

ERC-4337: a step towards post-quantum, not the whole way

The last clause of the card — no bundler holding an ECDSA key on the critical path — is about ERC-4337, the account-abstraction standard deployed on Ethereum today, and it is worth being precise about both what 4337 achieves and where it stops.

What it achieves

ERC-4337 lets an account be a smart contract that decides for itself what authorises an operation. A user signs a UserOperation; a bundler collects UserOperations from a separate mempool, packs them into a single call to the EntryPoint contract, and submits that call as an ordinary Ethereum transaction. During execution the EntryPoint calls each account’s validateUserOp, which can check any signature scheme it likes — including a post-quantum one.

This is genuinely a step towards post-quantum accounts, and Frost borrows from it directly. Authorisation became programmable without a protocol change. Accounts got counterfactual addresses: a 4337 wallet shows its CREATE2 address before deployment, funds accumulate there, and the first UserOperation carries the init code and repays the bundler from that balance — the loop Frost’s self-deploying first send follows. And the ERC-7562 validation rules that keep bundlers safe from griefing are the rules Frost’s ingress applies to VERIFY frames at the submission gate.

Where it stops

The envelope is still ECDSA. A UserOperation reaches the chain only inside a transaction that the bundler signs with a secp256k1 key, because that is the only kind of transaction the protocol recognises. The account’s post-quantum check runs inside a classical shell. Every operation on the chain still depends on at least one ECDSA signature being unforgeable.

A third party’s key is on the critical path. The bundler’s EOA must sign, must hold gas, and must be online. A quantum adversary who breaks that key cannot spend from a post-quantum smart account — validation still happens in the account — but can forge the bundler’s transactions, redirect the fees it collects as beneficiary, and impersonate it, and every other EOA the system depends on (the deployer of the EntryPoint, paymaster owners, the bundler fleet) remains classical. The account is post-quantum; the system around it is not.

Verification has to be paid for in EVM gas. Without a native verifier, checking an ML-DSA signature in validateUserOp means running the lattice arithmetic in EVM bytecode, at a cost of millions of gas per operation. This is exactly why Arc added an SLH-DSA precompile: to make 4337-style post-quantum validation affordable. Ethereum mainnet has no post-quantum precompile; the P-256 verifier it does have is another elliptic curve.

What Frost does instead

EIP-8141 lifts what 4337 does at the application layer into the transaction type. A frame transaction names its sender explicitly, carries the ML-DSA witness in an ARBITRARY signature entry the protocol does not interpret, and runs the account’s own VERIFY frame to decide whether the transaction is authorised. There is no envelope signature at all, so there is no bundler, no third-party key, and no classical primitive anywhere between the user’s ML-DSA key and the block. Verification is a precompile at 16,000 gas. A frame transaction can also carry up to 64 frames, so batching — one of 4337’s main attractions — is native too.

	ERC-4337 on Ethereum	Protocol registry	Frost (EIP-8141)
Where the post-quantum key lives	In the smart account	In shared registry state	In the account
Signature on the transaction the chain sees	The bundler’s ECDSA key	Depends on the chain’s transaction format	None — the sender is a field, and the account’s VERIFY frame decides
Pre-registration	None; counterfactual init code	One transaction per address, signed with the old key	None; the address is derived offline
Post-quantum verification	EVM bytecode, unless the chain adds a precompile	Native	Native: 16,000 or 10,500 gas
Classical key on the critical path	Yes — the bundler’s	At registration	No

Accounts and keys — how the account family works in practice, including the nonce rule that catches everyone.
Create a wallet — generate a key, derive the address, fund it, and send.
Why post-quantum — what a quantum computer does to Ethereum’s signatures, and why the fix is structural.