Finality certificates

ML-DSA-65 finality certificates, STARK-compressed and portable to light clients, bridges and new nodes, and how a verifier checks one.

A finality certificate is the proof that a point in Tenzro Network 1's history is final. Validators holding at least two thirds of the stake sign it with ML-DSA-65, a post-quantum signature scheme, and the network compresses it with a STARK proof. Anyone who knows the validator set can check it, with no need to trust the node that handed it over.

Finality certificates are how finality leaves the validator set: light clients follow the chain with them, bridges accept Tenzro state on the strength of them, new nodes start from snapshots anchored to them, and slashing uses them as evidence.

What a certificate covers

Validators sign checkpoints (see Consensus). A checkpoint commits to:

Field	Purpose
Chain and genesis	Binds the certificate to Tenzro Network 1, so it cannot be replayed on another chain
Epoch and position	Places the checkpoint in history; two different checkpoints for the same position are conflicting
Previous checkpoint	Chains checkpoints back to genesis
Blocks root	Commits to every block ordered since the previous checkpoint
State root	Commits to the executed ledger state
Next validator set	At an epoch boundary, names the validators and stakes for the next epoch

The certificate is the checkpoint plus a record of which validators signed and their signatures. Because each checkpoint commits to the one before it, a certificate for a recent checkpoint vouches for everything before it too.

Why ML-DSA-65

Signatures recorded today must stay unforgeable for as long as anyone relies on them. A bridge that accepts a certificate, or an archive that stores one as evidence, needs it to hold up after large quantum computers exist. ML-DSA-65 (FIPS 204) is a lattice signature scheme designed to resist quantum attack.

Validators sign with an in-memory session key that their TPM 2.0 or Secure Enclave certifies once per epoch. The certificate chain therefore runs from each signature, to a session key, to a hardware key registered in the validator set.

STARK compression

A set of individual post-quantum signatures from a large validator set is too heavy to post into another chain or keep on a phone. After a certificate forms, a validator produces a STARK proof that every listed signer made a valid ML-DSA-65 signature over the checkpoint. The proof system checks ML-DSA-65 lattice arithmetic natively, and the proof relies only on hash functions, so it stays quantum-safe too.

Compression happens off the critical path: consensus does not wait for it. Any validator may submit a valid proof, so compression does not depend on one party.

How a verifier checks a certificate

A light client, a bridge contract or a new node follows the same steps.

Know the validator set. Start from genesis, or from a validator set you already trust. Each epoch's last certificate names the next set, so you can walk forward epoch by epoch to the set that signed the certificate in hand.
Check the binding. The chain, genesis and epoch in the checkpoint must match the network and epoch you expect.
Check the quorum. Add up the stake of the validators marked as signers. It must be at least two thirds of that epoch's total stake.
Check the signatures. Either verify each signer's ML-DSA-65 signature and its session-key certification against the registered hardware key, or verify the STARK proof that attests to all of them at once.
Use the roots. Once the certificate checks out, its blocks root and state root are trusted. Verify a transaction, a receipt or an account balance with a Merkle proof against those roots.

validator set (epoch e)  ──►  quorum of stake signed?  ──►  signatures or STARK valid?
        ▲                                                            │
        │ next-set root in last certificate of epoch e-1             ▼
                                                  trusted blocks root and state root
                                                                     │
                                                                     ▼
                                                     Merkle proof for your transaction

A verifier needs no connection to any particular node: certificates, validator-set handovers and Merkle proofs can come from anywhere, because every step is checked.

Where certificates are used

Light clients. A light node tracks the validator set through epoch handovers and checks the latest certificate, then verifies the specific data it cares about against the certified roots. See the Run a light node tutorial.

Bridges. A bridge on another network accepts a message from Tenzro only once a certificate covering it verifies. The certificate is the bridge's source of truth, not a relayer's word. See Bridge.

New nodes. A node joining the network downloads a state snapshot and checks its state root against a certified root before applying it, then replays the blocks since. See State and snapshots.

Slashing. A validator signs at most one checkpoint for each position. Two signatures from the same validator over different checkpoints for the same position are transferable proof of double-signing, and anyone can submit them. The offender's bond is burned. See Slashing.

Reading finality over RPC

bash

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

Applications that move value on other chains should act only on certified finality.