Consensus and blocks

Frost’s consensus layer is Mysticeti V2, a DAG-based Byzantine fault tolerant protocol extracted from the Sui codebase. It answers one question — in what order did these transactions arrive? — and answers it without looking at what any of them do.

Ordering by DAG

Classical BFT protocols elect a leader per round, who proposes a block that everyone else votes on. Throughput is bounded by that one proposer, and a slow or malicious leader stalls the round.

DAG protocols invert this. Every validator continuously proposes blocks, and each block references blocks it has seen from other validators. The result is a directed acyclic graph that all honest validators converge on. Because the graph already encodes what everyone saw and when, the total order can be computed locally from the graph structure — the ordering itself needs no extra round of voting. Commitment happens as the DAG grows.

The practical effects on Frost:

• Every validator contributes throughput. There is no single proposer to saturate.
• No leader stall. A validator that goes quiet slows the DAG’s growth slightly; it does not halt a round.
• Ordering is cheap to agree on, which is what allows a short block interval.

The live network produces a block every 1 second.

From order to blocks

Consensus commits an ordered list of opaque transaction bytes. Turning that into an EVM block is the job of the driver, over a forced-transaction profile of the Engine API:

1. The driver takes the committed transactions in order.
2. It calls engine_forkchoiceUpdated with those transactions as an explicit payload attribute and a flag telling the execution layer not to add anything of its own.
3. It retrieves the built payload and delivers it back as the canonical head.

Because the consensus layer never validates transactions, the committed list can contain invalid ones. Every execution layer must therefore skip exactly the same transactions for exactly the same reasons. That determinism is the safety property the whole design rests on: nodes that disagree about validity would produce different state roots from identical input, which is a fork.

Frost’s answer is that skipping is a pure function of the ordered list and the parent state, tested directly by feeding known-invalid transactions past the submission gate and asserting every node produces byte-identical blocks.

Finality

Ordering is decided by consensus, so a transaction’s position is fixed the moment it is committed — there is no probabilistic settlement and no reorg window in the proof-of-work sense. Once committed, a transaction’s place in history does not change.

Note the distinction that catches people out at the RPC layer: when you submit a transaction, the acknowledgement you get back means ordered into a proposed block, not executed. To learn what actually happened — whether it succeeded, what it cost, what it logged — wait for the receipt as you would on any Ethereum chain.

Post-quantum block signatures

A chain whose accounts are post-quantum but whose consensus messages are signed with Ed25519 has simply moved the problem. Frost signs consensus post-quantum too, using a two-tier scheme:

Block keys sign the high-volume traffic: every consensus block, many per second. These use a compact lattice scheme (FN-DSA-512) chosen specifically because signature size dominates at that volume. They are ephemeral, scoped to an expiring window of rounds, tagged with their scheme, and rotated on a schedule.

Checkpoint root keys are long-lived and sign far less often. They authorise the checkpoint chain — hash-linked summaries that pin the consensus position, the execution-layer head, and the block-key schedule. These are signed with two independent schemes at once: one lattice-based (ML-DSA-65) and one hash-based (SLH-DSA-SHA2-192s). Both must verify. A cryptanalytic break in one family does not break the checkpoint chain.

The root keys delegate to the block keys, and every delegation is verified against the checkpoint roots. A new node joining the network verifies the checkpoint chain against the committee digest recorded in the genesis block, so its trust bottoms out in the chain definition itself.

Why split at all? Because the two tiers have opposite requirements. Block keys need to be small and fast and are used constantly, so they should be short-lived and replaceable. Root keys need to be conservative and rarely used, so they can afford a large hash-based signature and a strong custody boundary. See Two-tier consensus keys.

Transport

The links between validators use TLS with hybrid post-quantum key exchange (X25519MLKEM768) offered as the only key-exchange group — there is no classical fallback to negotiate down to. Validator identities are ML-DSA-65 raw public keys rather than classical certificates.

Offering no classical fallback is the point: a recorded session cannot be decrypted later by an adversary who acquires a quantum computer, which closes the harvest-now-decrypt-later exposure on the consensus mesh.

Next

• Architecture — how consensus, the driver and the execution layer fit together.
• Fees and ordering — what it means for users that ordering is decided without reference to fees.
• Node types — validators, followers, and history tiers.