Inside Tenzro's Consensus: DAG-Based BFT for a Network of Machines

A network that settles AI work between machines needs an ordering layer with three properties: every honest participant agrees on the same sequence, the sequence keeps moving when some participants fail or lie, and anyone outside the committee can check a result without trusting the node that served it. This post walks through how Tenzro's consensus meets those three requirements, in the order a transaction experiences them.

Why a DAG

Classic leader-based BFT protocols push every transaction through one proposer per round. The leader's bandwidth becomes the ceiling, and a slow leader stalls everyone. The DAG line of work, from Narwhal and Tusk through Bullshark, Mysticeti and Shoal++, separates two jobs. Every validator proposes in every round, so data dissemination uses the whole committee's bandwidth. Ordering is then a deterministic rule each validator applies to the graph it already holds, with no extra messages.

Tenzro follows that structure. Each validator proposes one vertex per round. A vertex strongly references a quorum of the previous round's vertices, introduces this validator's transaction batches, and acknowledges batches from others. The result is a graph in which every vertex points back at what its author had seen.

round r+1:   [A]  [B]  [C]  [D]
              | \/ | \/ | \/ |
round r:     [A]  [B]  [C]  [D]    <- leader slots in round r

Delivering vertices without signing them

A Byzantine validator could send different vertices to different peers for the same round. Tenzro prevents that with a reliable broadcast (ECHO, VOTE, ACK, READY, with a two-step fast path when a large ECHO quorum forms): every honest validator delivers the same vertex for a given author and round, or none.

Nothing inside a frame is signed. Validators talk over one QUIC stream per pair, set up with a four-message handshake that combines X25519 and ML-KEM-768 key exchange. Each side signs the handshake with a per-boot session key that its hardware key certified. After that, every frame carries a keyed BLAKE3 MAC and a strict sequence number. A handshake costs no hardware signature, and the hot path costs none either.

Batches move ahead of the vertices that introduce them, pushed to every validator. A batch executes once its introduction and a quorum of acknowledgements are ordered. Only transactions a mempool admitted can enter a batch, so only a valid, fee-paying transaction wakes an idle committee.

The commit rule

Stake is apportioned into integer seats, and every quorum is counted in seats: with n seats, f = (n-1)/3 and a quorum is n - f.

Each round has a small number of leader slots (two by default), each held by a different validator. Slots are decided in order, and each one is either committed or skipped:

• Direct commit. Next-round vertices from a quorum of seats reference the slot's vertex.
• Direct skip. Every seat's delivered next-round vertex fails to reference it.
• Indirect decision. Otherwise the slot waits for the first non-skipped slot at least two rounds later. If that slot commits, this one commits exactly when the later leader reaches it through strong references.

The safety argument is short. A quorum of first proposals contains at least f + 1 honest supporters, and every vertex two or more rounds later reaches a quorum of the next round. So a slot one validator commits directly is reachable from every later vertex, and a slot one validator skips directly is reachable from none. Every validator decides every slot alike.

A committed slot orders its not-yet-ordered causal history, by round then author, into one block. A slot that orders no transactions makes no block, so heights, storage and sync grow only with real activity. When nothing waits to be ordered, rounds slow to a heartbeat interval; a new batch returns the committee to full pace within a round or two.

The leader schedule weights validators by seats and recent behaviour. It changes only at checkpoints and draws its seed from the committed prefix two checkpoints back, so no validator can grind it.

Checkpoints make finality portable

Ordering alone gives finality to the committee. A light client, a bridge or an auditor needs something it can verify independently. That is the job of checkpoints.

At the first committed leader at least checkpoint_interval_ms (500 ms by default) after the previous checkpoint, the validators decide a checkpoint over the blocks since. Its body names the chain, epoch, index, previous checkpoint, height range, a state root, a statement root and, at an epoch's end, the root of the next committee. Each validator persists that it is about to vote, then signs. A quorum of votes is a certificate.

The signing key matters. A validator's consensus key is a composite of ECDSA P-256 and ML-DSA-65. The P-256 half lives in a TPM or Secure Enclave, and the ML-DSA-65 half is derived from the machine's hardware root for each signature and wiped afterwards. Votes are signed by an in-memory session key, which the hardware key certifies once per epoch and on every boot. Every vote and every certificate carries that session certificate, so certified finality traces back to a hardware key.

The RPC reports two heights:

{"jsonrpc": "2.0", "id": 1, "method": "tenzro_getFinality", "params": []}

ordered is final for every honest validator the moment it is ordered. certified is covered by a certificate and is what a bridge acts on. tenzro_getCheckpointCertificate returns the certificate and the session certificates it names, verifiable against the epoch's committee from tenzro_getCommittee with no Tenzro node in the loop.

Two votes for different bodies at one index are complete evidence of equivocation. A transaction carrying both votes is verified by the execution layer, which slashes the signer's bond into an insurance pool.

Epochs and how validators join

A validator registers with a RegisterValidator transaction carrying both halves of its consensus key, its node key and two proofs of possession. No network address is registered. Publicly, a validator shows its key, stake, announcements and certificates, never a location; its endpoint is sealed to each committee member's disclosure key.

The checkpoint that ends an epoch commits the next committee's root, which every node derives from the same executed state. The old committee keeps ordering for a small number of further checkpoints (two by default), then stops, and the new committee starts from the last of them. A follower whose key is seated in the next committee starts validating at that handover. A machine without hardware-held keys can still follow the chain as a full node; it cannot validate.

Followers never trust a block on gossip alone. They hold blocks until a certificate covering them arrives, check that the blocks rebuild the certified blocks root, execute them and compare the certified state root.

Conformance against a formal model

Consensus code fails in the interleavings nobody wrote a test for. Tenzro keeps two kinds of formal model beside the code.

A TLA+ model covers the ordering, checkpoint and epoch layers, with Byzantine authors who may send different first proposals to different validators. Its checked invariants are agreement on the commit sequence, no two certified bodies for one checkpoint index, a consistent handover between epochs, and agreement on which batches are ordered where.

Quint specifications cover the commit rule and checkpoint voting. They are checked for safety and liveness by random simulation at committee sizes of four and seven, with leader tables redrawn at checkpoints and validators restarted from their journals. Reachability witnesses make sure the interesting states (a skipped slot, a quiescent network, a restarted validator deciding again) are actually reached, so a property cannot pass vacuously.

The decisive step is conformance. Executions generated from the Quint model are replayed step by step through the real consensus core. The replay plays the network and the Byzantine validators; each honest validator is the production core. After every step the harness compares each core's delivered vertices, first proposals, decided slots, released order and recovery state with what the specification says. A divergence is a bug in one of them, found with the exact sequence that produced it.

What this means for infrastructure operators

A validator needs a TPM or Secure Enclave, outbound connectivity and no inbound port. It does not publish its address. Finality you can hand to a third party is a certificate, not a dashboard. And the protocol's claims are tied to models that are checked against the shipping code, not only argued in a paper.

Where Tenzro fits

Built: the DAG ordering with reliable broadcast and multi-slot leaders, hardware-held composite ML-DSA-65 and P-256 consensus keys, checkpoint certificates with two reported finality heights, equivocation evidence and slashing, epoch handover, and the TLA+ and Quint models with step-by-step conformance replay. The network is live in preview; governance decides the steps to testnet and mainnet, and with them the committee and its parameters. We do not publish latency or throughput figures here; they come from measured runs, not from the design.