Post-quantum security

Joltzu's direction is to make everything the protocol controls post-quantum, and to keep ordinary user accounts on secp256k1 because exchanges and standard wallets need it. Any account can add a post-quantum key without changing its address.

Most of this is not in the running node yet. As of 31 October 2026 the reference node still uses BLS12-381 for validators. Its validator and randomness migration is in progress, and the other items are planned. Nothing on this page describes a deployed network.

Area	Decision	Status
Validators	ML-DSA-44 only; BLS12-381 is removed	In progress
Block randomness	Hash-based per-height reveals; the threshold beacon is removed	In progress
Security Council, code admission, SAFU, oracles	ML-DSA-44 required	Planned
Validator peer links	Hybrid X25519MLKEM768 pinned; ML-DSA-65 identities	Planned
User accounts	secp256k1 stays; any account can add ML-DSA in place	Planned
Per-asset committees and owner-chosen signers	secp256k1 for now; typed signatures when a user needs them	Later
Application VRF (JSN)	Will be quantum safe; construction not chosen	Planned
Frame transactions, EVM verifier, classical sunset	Designed for, not built	Deferred

The threat

No machine can break these signatures today. Google's March 2026 estimate puts a secp256k1 break at no more than 1,450 logical qubits and under 500,000 physical qubits, assuming superconducting hardware with 10⁻³ physical error rates.

Joltzu's 500 ms slots make it hard to intercept a transaction before it lands, if it is included promptly. The larger risk is recovering a key at rest: an account's public key can be recovered from any signature it has made, and validator keys are public by design. State, receipt and block commitments use Keccak-256 and need no replacement.

Validators and certificates

Votes, proposals, new-views, group voting, double-sign evidence and proofs of possession all move to ML-DSA-44 (FIPS 204). A public key is 1,312 bytes and a signature is 2,420 bytes.

These signatures do not aggregate, so a certificate lists its signers' addresses with one signature each, and active committees are capped at 32. Quorum and weight rules do not change. There is no hybrid: a practical break of ML-DSA would allow forged finality with no second signature to stop it. That risk is accepted, and changing scheme stays contained because consensus takes its signature types and sizes from one module.

ML-DSA signatures are not unique, so two signatures over the same vote can differ. Compare signed statements, never signature bytes, when looking for duplicates or equivocation.

These capacity figures are calculated from the limits above. They are not measurements:

Quantity	BLS12-381	ML-DSA-44
Commit certificate, 22 of 32 signers	About 536 B	About 53.7 KB
Certificate storage, a block in every slot	About 93 MB/d	About 9.3 GB/d
Vote traffic per validator, 32 validators, all-to-all	Small	About 465 KB/s
Vote verification per round, 32 validators, one core	Not measured	About 7.4 ms

Empty-block suppression lowers the storage figure and replicated groups raise it. Running 32 validators inside a 500 ms slot across real networks has not been tested, and it is the result most likely to change the committee limit.

Randomness

A proposer that could produce many valid signatures could keep trying until the output suited it, so block randomness cannot come from ML-DSA.

Each validator instead commits to a Merkle root over per-height secrets, as part of its committee record. A proposal reveals the secret for its height with its Merkle path, which gives exactly one valid value per height. The block's randomness still chains the parent's randomness with the reveal. Checking it takes a few dozen hashes and no state, so light clients and catch-up are unaffected.

The threshold beacon and its distributed key generation are removed, because no standardized post-quantum equivalent exists. The epoch seed comes from the randomness of the block that carries it, so that block's proposer can bias the seed by withholding the block, at the cost of losing it. This is an accepted limit of this profile.

Application VRF

The application VRF will be quantum safe. It runs in JSN, separately from block randomness, and it is not part of the node's migration. Its proofs use secp256k1 today and its public key appears in every fulfillment, so a machine that can break secp256k1 could recover the proving key and would then know each output as soon as a request is committed.

The construction is not chosen yet. RFC 9381 only defines RSA and elliptic-curve VRFs, we know of no standardized post-quantum VRF, and ML-DSA does not fit for the reason given above. The hash-based reveals used for block randomness are one candidate, because a committed Merkle root fixes exactly one value for each position, although each position could serve only one request and the prover would need a fresh root whenever a tree runs out.

A coordinator fixes its proving identity when it is deployed. If the new construction arrives after a public deployment, consumers will have to move to a new coordinator.

Accounts

This builds on native account policies, which work for every address, including one created by an exchange or wallet.

• The address stays the same. Stored signers remain 20-byte addresses, and an ML-DSA signer is derived from the hash of a type byte and its public key. An owner adds one by updating the account's policy, and balances and positions stay where they are.
• The old key can be retired. Leaving it out of the policy retires it. A retired key then fails at block admission, firm quotes, AMM permit and ecrecover.
• Later schemes need no account change. Each signature names its kind, so a scheme such as FN-DSA is a new kind and a verifier.
• Approvals are larger. An upgraded account's approval carries about 3.7 KB, paid for as call input. It acts through a relayer calling the account service until frame transactions exist.

A policy does not move anyone by itself. An exchange that signs standard Ethereum transactions stays on secp256k1 until it chooses to upgrade. Passkeys stay on P-256, which is not post-quantum. User-signed services such as grants, recovery, vouchers and quotes keep secp256k1 for now.

What to do

• Holders: nothing today. Upgrade an account's signers once the feature ships and your wallet supports it, and do it before a machine that can break secp256k1 exists.
• Contract developers: do not assume ecrecover keeps working for every address. Once this ships, it fails for a key its account has retired. BN254, BLS12-381 and KZG precompiles stay for EVM compatibility, but will not be safe for authorization once quantum machines exist.
• Validator operators: expect larger certificates and more vote traffic, and plan storage accordingly, since finality archives are never pruned. Validator registration changes because key sizes change, and a production signer has to support ML-DSA.

Deferred work

• Frame transactions. EIP-8141 would let post-quantum accounts send transactions directly. It is a draft that can still change, and envelope type 0x06 is being kept free for it.
• EVM verifier. Contract wallets need ML-DSA verification once Ethereum settles on an address and format.
• Classical sunset. At a scheduled height, classical signatures would stop authorizing anything. This needs frame transactions, wallet support and a decision on funds that never migrate. The recommended default is to freeze those funds and leave them claimable through a future proof of key ownership, never burning or reassigning them. The Security Council has no pause or upgrade authority, and this adds none.

Until a sunset, Joltzu is not fully quantum-resistant: any account still relying on secp256k1 or a passkey is open to a machine that can break it.

Ethereum's position

Checked on 31 October 2026. Ethereum's post-quantum team estimates that its protocol upgrades could be completed by 2029, with no fixed date and full execution-layer migration taking years longer. Compatibility with standard EVM tools depends only on the execution layer, so Joltzu's validators do not need to match Ethereum's signatures.