Two-tier consensus keys

A chain whose user accounts are post-quantum but whose consensus messages are signed with Ed25519 has not solved the problem, it has moved it. So Frost signs consensus post-quantum too.

But “post-quantum” is not one requirement here, because consensus signing has two workloads with opposite characteristics:

	Block signatures	Checkpoint roots
Frequency	Many per second, forever	Rarely
Size sensitivity	Extreme — signature is a large fraction of each block	Negligible
Lifetime	Short-lived, replaceable	Long-lived, hard to replace
Custody	Must be online on a validator	Can be offline, in strong custody

Optimising both with one key and one scheme means compromising both. Frost splits them.

The block tier

Every consensus block carries a signature, many times per second. At that volume, signature size is bandwidth and is storage.

Block keys therefore use FN-DSA-512, a compact lattice scheme chosen specifically for its small signatures. The effect is measurable: moving to it cut the mean proposed block from roughly 4.3 KB to roughly 2.2 KB under identical load.

These keys are deliberately disposable:

Ephemeral, scoped to an expiring window of consensus rounds.
Scheme-tagged, so the scheme can change per key rather than per network.
Rotated on a schedule, well before their window expires.
Delegated from the root tier, so replacing one is routine.

Making the high-volume key short-lived is what allows it to be optimised aggressively for size. A key that only has to survive a bounded window can be held online without that being the chain’s weakest point.

The checkpoint root tier

Checkpoint roots sign the checkpoint chain: hash-linked summaries, each a couple of hundred bytes, pinning the consensus position, the execution-layer head, and the block-key schedule. They are the anchor a new node verifies against, and they are what makes pruning safe.

They sign far less often, so they can afford to be conservative — and they are conservative in the strongest available sense: each checkpoint is signed with two independent schemes, and both must verify.

ML-DSA-65 — lattice-based (FIPS 204).
SLH-DSA-SHA2-192s — hash-based (FIPS 205).

The two rest on different mathematical assumptions. A cryptanalytic break in lattice problems would compromise ML-DSA and FN-DSA together; it would not touch SLH-DSA, whose security reduces essentially to the security of a hash function. Requiring both means the certified history survives the failure of either family.

This is the right place to spend that redundancy. Hash-based signatures are far too large for per-block use, but on a summary signed occasionally the cost disappears.

Delegation and anchoring

The root keys delegate authority to the per-validator block keys, and every delegation entry is verified against the checkpoint roots. So the trust chain is:

genesis committee digest   (in the genesis block's extraData)
        ↓ verified against
checkpoint chain           (dual-signed by the root keys)
        ↓ authorises
block-key schedule         (per-validator, expiring, scheme-tagged)
        ↓ signs
consensus blocks

A node joining the network verifies the checkpoint chain against the committee digest recorded in genesis, then installs the block-key schedule with every delegation checked. Its trust bottoms out in the chain definition itself — not in whoever served it the data.

That is what makes checkpoint-based bootstrap safe: a new node does not replay from genesis, it verifies a chain of certificates rooted in something it already had to trust to be on this network at all.

Rotation as a routine operation

Block-key rotation is an ordinary per-validator operation with a defined lifecycle in the checkpoint chain, and it has been exercised in production — including a live scheme migration, rolled out as a sequence of normal rotations rather than a coordinated network event.

Making rotation routine matters more than it sounds. A rotation path that is only used in emergencies is a rotation path nobody knows works. Frost runs a rotation drill on a schedule for exactly this reason.

There is also a freshness guard: nodes follow the chain only while the checkpoint chain remains fresh, alarming and then halting if it falls too far behind. A stale checkpoint chain means the delegation authority is no longer being confirmed, and continuing to follow blindly is the failure mode this prevents.

Custody

The root keys have a custody boundary separate from the online block keys — they are not needed to produce blocks, only to sign checkpoints and authorise delegations. That is the whole point of the split: the key that must be online constantly is not the key whose compromise is hardest to recover from.