Tenzro DAG Consensus

Abstract

Tenzro DAG Consensus (TDC) is our post-quantum consensus protocol and the consensus layer of Tenzro Network 1. Every validator proposes in parallel each round, building a directed acyclic graph (DAG) of vertices from which a total order is derived. Validators communicate over channels keyed by a hybrid of X25519 and ML-KEM-768, with handshakes signed by each validator's hardware-rooted composite key (ML-DSA-65 and P-256). Periodic checkpoints are signed with ML-DSA-65 into finality certificates that light clients, bridges and new nodes can carry and check, and that serve as evidence for slashing. Certificates are compressed with STARK proofs. Validator keys are rooted in hardware, and votes are signed with an in-memory session key that the hardware certifies once per epoch.

DAG-based BFT consensus is an established family of protocols. TDC builds on that family; what it adds is a combination: post-quantum authenticated ordering, transferable post-quantum finality certificates, hardware-rooted validator keys and STARK-compressed certificates, together in one permissionless network.

1. Introduction

A settlement network for autonomous agents has four consensus requirements.

1. It must order transactions from many validators without one leader limiting capacity.
2. Its finality must be transferable. A bridge, a light client or a node joining later must be able to check that a block is final without trusting the node that told it so.
3. Its finality must be accountable. If validators sign conflicting histories, the evidence must identify them so their bonds can be slashed.
4. It must remain sound against an adversary with a quantum computer, including one that records traffic and certificates today and attacks them later.

TDC meets these requirements with two layers. The ordering layer is a DAG protocol whose critical path runs on authenticated post-quantum channels. The certificate layer turns ordered history into signed, portable, accountable finality certificates.

2. System model

• Validators: a set of n validators per epoch, weighted by bonded stake. TDC is safe while the Byzantine stake f satisfies n = 3f + 1, that is, while less than one third of stake is faulty.
• Network: partial synchrony. Messages may be delayed arbitrarily before an unknown global stabilisation time and are delivered within a bound after it. Safety holds at all times; liveness holds after stabilisation.
• Cryptography: a collision-resistant hash; ML-KEM-768 and X25519 for key exchange; ML-DSA-65 and P-256 for signatures, combined in a composite construction in which a signature is valid only if both legs verify.
• Hardware: each validator's long-term key is rooted in a TPM 2.0, a Secure Enclave or a passkey. TDC does not assume that trusted hardware prevents misbehaviour. Hardware protects an honest operator's keys; it is not part of the quorum arithmetic.

3. Validator keys

3.1 The hardware-rooted identity key

Each validator has a long-term identity key: a composite of ML-DSA-65 and P-256, rooted in the validator's hardware. Any TPM 2.0 machine can run a validator. Signing keys are derived from the hardware on demand, used in memory and wiped after use. There is no key file to copy and no seed phrase to steal.

The identity key is used rarely:

• to register the validator, with a proof of possession over the registration payload and, where the hardware provides it, key-attestation evidence;
• to sign channel handshakes, once per connection;
• to certify the validator's session key, once per epoch.

3.2 The per-epoch session key

At the start of each epoch, a validator generates an ML-DSA-65 session key in memory. Its identity key signs a certification binding the session key to the validator, the chain, the genesis and the epoch. The certification is published with the epoch's validator set, so every verifier can map a session key back to a registered validator.

The session key signs checkpoint votes for that epoch. It lives only in memory and is discarded at the end of the epoch. This keeps the hardware off the hot path of consensus: a TPM signs a handful of times per epoch, while votes are signed at the rate the protocol needs. A vote signed by a session key is as attributable as one signed by the identity key, because the certification chains it to the validator's hardware-rooted identity.

3.3 Double-sign protection

Before a validator signs a checkpoint vote, it records the highest checkpoint it has voted on. Where the hardware supports it, that high-water mark is bound to a monotonic hardware counter rather than a file, so restoring an old disk image cannot trick an honest validator into signing twice.

4. Post-quantum validator channels

Every pair of validators holds a consensus channel.

1. The two sides run a hybrid ephemeral key exchange: X25519 and ML-KEM-768.
2. Each side signs the handshake transcript with its composite identity key. The signed context binds the chain, the genesis and the epoch, so a handshake cannot be replayed on another network or in another epoch.
3. Per-direction symmetric keys are derived from both shared secrets. Every message carries a message authentication code and a per-direction sequence number.
4. Channels are re-keyed every epoch.

To impersonate a validator, an attacker must forge both ML-DSA-65 and P-256. To read or forge channel traffic, an attacker must break both ML-KEM-768 and X25519. The handshake costs one hardware signature per connection, so the hardware is not on the per-message path.

The peer-to-peer transport's own endpoint keys are not trusted for consensus. Only the hardware-authenticated channel is.

5. Dissemination and availability

Each validator runs a batch lane. It drains its mempool into batches and disseminates them to the other validators. For larger validator sets, batches are erasure-coded so that each validator sends slivers rather than full copies.

Availability is attested inside the DAG. A vertex lists the digests of batches its author holds. A batch becomes eligible for ordering once a quorum of 2f + 1 acknowledgements for it is reachable from a committed anchor. No separate availability certificate is needed.

6. The ordering layer

6.1 Vertices and rounds

In each round r, every validator creates one vertex. A vertex contains:

• the round, the author and the epoch;
• references to at least 2f + 1 vertices from round r - 1;
• availability acknowledgements for batches;
• the digests of the batches it proposes;
• a timestamp.

A vertex is identified by the hash of its encoding.

6.2 Reliable broadcast

Each vertex is disseminated with a reliable broadcast. Echo and ready messages carry only the vertex digest and travel over the authenticated channels. Reliable broadcast guarantees that honest validators deliver the same vertex for each author and round, or none. An author that tries to equivocate cannot get two different vertices delivered for the same slot.

A validator enters round r + 1 once it has delivered 2f + 1 vertices from round r, including the round's leader vertex, or once a leader timeout expires.

A missing vertex is fetched by digest from any peer. It is accepted if its digest is one the validator delivered or one referenced by a vertex it delivered, which authenticates the content without a further signature.

6.3 Leaders and commit

Each round has a designated leader vertex.

• Direct commit: a leader vertex commits once 2f + 1 vertices of the next round reference it.
• Skip: a round's leader may be skipped only when 2f + 1 next-round vertices do not reference it. Those non-references are the vertices themselves, so skipping costs no extra message.
• Indirect commit: earlier leaders commit through the causal history of a later committed leader.

Because any two quorums of 2f + 1 intersect in at least one honest validator, every later committed leader has an earlier committed leader in its causal history. All honest validators therefore commit the same sequence of leaders.

6.4 From DAG to blocks

When a leader commits, the validator orders the part of its causal history not yet ordered, deterministically by round, author and digest, and keeps only batches with a quorum of availability acknowledgements. The result is one ordered segment, which becomes one block. The block's timestamp is the median of the timestamps of the committed leader's parents. It is monotone and attested by a quorum of validators, which gives the ledger a deterministic block time.

Execution runs on the ordered block with Block-STM parallel execution. The execution layer and the state are independent of the consensus design.

6.5 Leader schedule

The leader of each round is drawn in proportion to stake and a behaviour weight that reflects the validator's record of producing and referencing vertices. The random seed comes from an earlier finalised checkpoint, so it is fixed only shortly before it is used and cannot be chosen by any single validator. Trusted hardware does not weight the schedule.

A DAG does not stall when one leader is offline. Only that round's anchor is delayed, and the next leader commits it indirectly.

6.6 Censorship and tail forks

Every validator's batches travel in its own vertices. A vertex delivered to a quorum is eventually referenced and ordered, so a Byzantine leader cannot exclude another validator's transactions. A skipped leader's vertex is still ordered through the causal history of the next committed leader, so a Byzantine next leader cannot orphan it.

7. Two levels of finality

TDC exposes two levels of finality.

Ordered finality is fast and safe under the fault assumption, but it is not transferable: it cannot be proved to someone outside the validator set. Certified finality is. Bridges and light clients always use certified finality.

8. Checkpoints and finality certificates

8.1 Checkpoints

At regular intervals, validators take a checkpoint at a committed leader. The checkpoint message is a hash over:

domain tag  ||  chain id  ||  genesis hash  ||  epoch  ||  checkpoint index
||  previous checkpoint digest     (a hash chain of checkpoints)
||  blocks root                    (Merkle root of the blocks since the last checkpoint)
||  state root                     (the executed state at a fixed lag)
||  statement root                 (validator-attested statements, such as availability
                                    and proof-verification commitments)
||  next validator set root        (at epoch boundaries only)

The domain tag, chain id, genesis hash and epoch make a checkpoint impossible to replay on another chain or in another epoch.

8.2 Votes

Each validator checks that the checkpoint's state root matches its own executed state, records the checkpoint in its double-sign guard, and signs the checkpoint with its ML-DSA-65 session key. Votes are sent to all validators.

8.3 Certificates

A finality certificate is the checkpoint, a signer bitmap and a quorum of ML-DSA-65 signatures carrying at least 2f + 1 of stake. Every validator forms it locally once enough votes arrive.

Anyone can verify a certificate with public information: the validator set for the epoch, each validator's session-key certification, and the signatures. Because checkpoints form a hash chain, a verifier that trusts one certificate can follow the chain forward. Epoch handovers are certified the same way: the last checkpoint of an epoch commits the root of the next validator set and is signed by the outgoing set.

A node joining the network syncs state from a snapshot anchored to a certified checkpoint's state root. It does not need to trust the peer that serves the snapshot.

9. STARK compression

A raw certificate carries one ML-DSA-65 signature per signer. To make certificates cheaper to carry and check, validators periodically produce a compact certificate: a STARK proof, built with Plonky3, that each validator named in the bitmap produced a valid ML-DSA-65 signature over the checkpoint. The proof system checks ML-DSA-65's lattice arithmetic natively.

• Proving is off the critical path. A missing or late compact certificate never delays consensus.
• Any validator may prove. A deterministic assignment names a primary prover and fallbacks for each compact certificate, and anyone may submit a valid proof.
• The proof is configured for soundness appropriate to permanent evidence.
• Raw certificates remain canonical. A compact certificate is an efficient way to verify the same statement, not a replacement for it.

Compact certificates are useful where verification is expensive or remote: in contracts on other chains, on phones and in light clients. See Proofs on Tenzro.

10. Accountability and slashing

Evidence is transferable. Anyone who holds it can submit it, and the chain verifies it deterministically. Slashed stake is burned, not redistributed, so no validator gains from a peer's slashing.

11. Epochs and reconfiguration

Validator admission is permissionless. A new validator registers with its hardware-rooted key and a bond, and is admitted at the next epoch boundary.

• An epoch ends at a checkpoint that reaches the epoch's height or time boundary. That checkpoint commits the next validator set.
• Churn per epoch is bounded, so each new set overlaps the previous one by enough stake that light clients following the chain of handovers always retain an honest overlap.
• The outgoing set confirms a short run of further checkpoints and then stops. The incoming set starts the next epoch's DAG anchored to those certified checkpoints.
• Channels are re-keyed and session keys are replaced at every epoch.

12. Safety and liveness

Ordering safety. Reliable broadcast gives every honest validator the same vertex for each author and round. The commit rule's quorum intersection ensures that honest validators commit the same sequence of leaders, and ordering is a deterministic function of the committed history. The availability filter and timestamp rule are deterministic functions of that history, so they do not affect agreement.

Certificate safety. An honest validator signs only a checkpoint it computed from its own ordered history and its own executed state, which ordering safety makes identical across honest validators. Two certificates for different checkpoints at the same index therefore require at least f + 1 validators to sign twice, and the certificates themselves identify them. Compact certificates add one assumption: the soundness of the STARK.

Epoch safety. The incoming set anchors to a checkpoint certified by the outgoing set, and the outgoing set stops after a bounded confirmation window, so two sets never order concurrently beyond the certified boundary.

Liveness. After network stabilisation, reliable broadcast terminates, rounds advance on 2f + 1 vertices, and an honest leader collects the references it needs to commit. Checkpoints are live while ordering is live and a quorum of validators responds. Compact certificates are live if at least one honest prover exists, and never block consensus.

13. Attack surface

14. Conclusion

TDC orders transactions from every validator in parallel over post-quantum channels, turns that order into ML-DSA-65 finality certificates that anyone can carry and check, compresses them with STARK proofs, and makes double-signing provable and slashable. Validator keys are rooted in hardware, with session keys that keep the hardware off the hot path. For operational detail, see Consensus, Finality certificates, Validator lifecycle and Slashing.