Tenzro DAG Consensus (TDC)

Tenzro DAG Consensus (TDC) is our post-quantum consensus protocol. It orders every transaction on Tenzro Network 1 and produces finality that anyone can carry and check. TDC builds on the DAG family of Byzantine fault tolerant protocols; what it adds is the combination of post-quantum ordering, transferable post-quantum finality certificates, hardware-rooted validator keys and STARK compression, together in one protocol.

Properties

• Parallel proposals. Every validator proposes in parallel each round, so no single leader limits throughput.
• Post-quantum channels. Validators talk over channels keyed by X25519 plus ML-KEM-768, with a handshake signed by each validator's hardware key (ML-DSA-65 plus P-256).
• Post-quantum finality. Finality certificates are signed with ML-DSA-65, so finality stays quantum-safe for as long as anyone relies on it.
• Portable finality. Certificates are STARK-compressed and can be checked by light clients, bridges and new nodes without trusting a server.
• Accountability. A validator that signs two conflicting checkpoints can be slashed, with the certificates as evidence.
• Hardware-rooted keys. Any TPM 2.0 machine can run a validator.

Safety holds while validators controlling less than one third of the stake are faulty, as in other BFT protocols.

Validators and keys

Each validator has a hardware key in its TPM 2.0 or Secure Enclave. Signing keys are derived from the hardware on demand, used in memory and wiped; there is no validator key file.

Keeping the hardware off the hot path matters for speed, so at the start of each epoch the hardware certifies an in-memory session key. The validator signs its votes for that epoch with the session key. Anyone checking a vote can follow the chain back: the vote is signed by a session key, the session key is certified by the hardware key, and the hardware key is registered in the validator set.

Channels

Every pair of validators holds an authenticated channel. The handshake runs a hybrid key exchange, X25519 plus ML-KEM-768, and each side signs the handshake transcript with its hardware key, a composite ML-DSA-65 plus P-256 signature bound to the chain and the epoch. Traffic on the channel is authenticated with keys derived from both shared secrets, so forging a message means breaking both key exchanges, and impersonating a validator means forging both signature schemes. Channels are re-keyed every epoch. See Networking.

Rounds and the DAG

Consensus runs in rounds. In each round every validator:

1. Collects pending transactions into batches and disseminates them to the other validators.
2. Proposes one vertex for the round. The vertex names the batches it carries and references vertices from the previous round, from validators holding at least two thirds of the stake.
3. Moves to the next round once it has received enough vertices for the current one.

The references form a directed acyclic graph (DAG). Because every validator proposes every round, the network's capacity grows with the validator set instead of being limited by one proposer.

Commit and ordering

Each round has a leader vertex, chosen from a schedule weighted by stake. A leader vertex commits once enough vertices in the next round reference it. When a leader commits, every vertex in its causal history that is not yet ordered is ordered deterministically, and the transactions in those vertices become the next block for the ledger.

If a leader is slow or offline, its round is not lost. The next leader that commits orders the earlier vertices through its own history, so every validator's batches are eventually ordered and no leader can censor them by leaving them out.

Block time is deterministic, and a block's timestamp is derived from the vertices that committed it rather than from a single proposer's clock.

Checkpoints and finality certificates

At regular points the validators sign a checkpoint. A checkpoint commits to:

• the chain and the epoch;
• the previous checkpoint, so checkpoints form a hash chain back to genesis;
• the blocks ordered since the previous checkpoint;
• the state root the validators executed;
• at an epoch boundary, the next validator set.

Each validator checks that its own executed state matches before it signs. Signatures from validators holding at least two thirds of the stake form a finality certificate, signed with ML-DSA-65. The certificate is then compressed with a STARK proof, off the critical path, so it is compact enough to carry into light clients and other chains. See Finality certificates.

Epochs

The validator set changes only at epoch boundaries. New validators registered during an epoch become active at the next boundary; validators that exit leave at the boundary. The last certificate of an epoch is signed by the outgoing set and names the incoming set, so a verifier can follow the chain of validator sets from genesis to today. Channels are re-keyed and new session keys are certified at every boundary. See Validator lifecycle.

Accountability

Signing two different checkpoints for the same position is the one thing an honest validator never does. Because checkpoint signatures are transferable, two such signatures are proof anyone can submit, and the offender's bond is burned. Operators can also be slashed for a provable breach of their own signed operator policy. See Slashing.

What applications see

Applications read finality through the RPC:

curl -s https://rpc.tenzro.xyz \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_getFinalizedBlock","params":[]}'

Subscribe to BlockFinalized and TransactionFinalized events to react as soon as a block is final. See Events.

The active validator set is open to read:

tenzro validator list-active