Proofs on Tenzro

Abstract

Tenzro Network 1 uses Plonky3 STARKs as its proof system. STARKs need no trusted setup, rest on hash functions rather than elliptic-curve assumptions, and verify quickly relative to the computation they prove. On Tenzro they do three jobs: compressing finality certificates so light clients, bridges and remote verifiers can check finality cheaply; proving settlement state transitions so many small payments can be committed as one; and proving facts about credentials without revealing them. Proofs are verified by validators and committed through consensus, so contracts can act on them at the cost of a lookup. Inference is verified differently: TEE-first, with signed receipts and re-execution challenges.

1. Introduction

A proof system lets one party convince another that a computation was done correctly without the verifier repeating it. For a network that settles machine commerce and wants its finality to be portable, three properties matter most:

1. Transparent setup. No trusted ceremony and no per-circuit proving keys that someone must be trusted to have destroyed.
2. Post-quantum plausibility. Soundness should rest on assumptions that are not known to fall to quantum computers. Hash-based STARKs fit; pairing-based systems do not.
3. Fast verification. Verification must be cheap enough for validators, light clients and contracts.

Plonky3 STARKs meet all three.

2. The proof system

• Arithmetisation: algebraic intermediate representations (AIRs), in which a computation is expressed as a trace of rows and constraints between them.
• Field: KoalaBear, a 31-bit prime field suited to fast arithmetic on commodity processors.
• Hash: Poseidon2 inside the proof system, used for commitments and the Fiat-Shamir transcript. The hash is a configuration of the proof system and can be changed without changing the statements being proved.
• Commitment scheme: FRI, a hash-based polynomial commitment.

2.1 Soundness configuration

Some Tenzro proofs are permanent evidence: a compact finality certificate may be checked years after it was made. Tenzro therefore configures its proofs for proven soundness at a level appropriate to permanent evidence, not only for conjectured soundness. Configurations are fixed per circuit and published, and only Plonky3 proofs under the published configuration are accepted. Proofs from other systems, or under other configurations, are rejected.

2.2 The proof envelope

Every proof travels in one envelope, whatever circuit produced it:

One verification entry point reads the circuit id, selects that circuit's verifier and published configuration, and checks the proof against the public inputs. The same entry point serves the RPC, the web API, MCP tools and the settlement engine, so a proof accepted by one surface is accepted by all of them, and a proof rejected by one is rejected by all.

2.3 Why not a pairing-based system

Pairing-based proof systems produce smaller proofs, but they need a trusted setup, either per circuit or universal, and their soundness rests on elliptic-curve assumptions that a large quantum computer breaks. For evidence that must remain valid for years, such as finality certificates carried by bridges, Tenzro chooses the transparent, hash-based construction and accepts larger proofs in exchange.

3. Circuits

tenzro zk circuits lists the circuits a node supports.

4. Compressing finality certificates

A finality certificate in Tenzro DAG Consensus is a checkpoint, a signer bitmap and a quorum of ML-DSA-65 signatures. Carrying and checking every signature is fine for validators but costly for a contract on another chain or for a phone.

A compact certificate replaces the list of signatures with a STARK that proves the same statement: that validators holding a quorum of stake each signed the checkpoint with a valid ML-DSA-65 signature. The certificate circuit checks ML-DSA-65's lattice arithmetic natively: number-theoretic transforms, polynomial products, norm and range checks, and the hash computations that derive the signature challenge. The validator set's public keys are fixed per epoch and precomputed into the circuit's preprocessed columns, and the signer bitmap is bound to the stake committed for that epoch.

Design rules for compact certificates:

• Off the critical path. Proving never delays consensus. A compact certificate is produced after the raw certificate exists.
• Open to any prover. A deterministic assignment names a primary prover and fallbacks for each compact certificate, and anyone may submit a valid proof.
• Raw certificates remain canonical. The compact certificate is a cheaper way to verify the same statement; the raw certificate is the ground truth.

Because checkpoints form a hash chain and each epoch's last checkpoint commits the next validator set, a verifier can follow compact certificates across epochs from a checkpoint it already trusts.

5. Settlement proofs

Machine commerce produces many small state updates: micropayment channel balances, metered session captures, batched settlements. Recording each on the ledger is wasteful. The settlement circuit proves that a sequence of updates was applied correctly, so the ledger can commit the result with a proof rather than every step.

A settlement proof shows that:

• every balance change conserves value and no balance goes negative;
• fees and settlement shares are computed by the published rules;
• every update carries a valid signature from the party it debits.

See Settlement for the Machine Economy.

6. Identity proofs

A service may need to know that a caller meets a requirement, such as holding a valid credential of a certain kind, without learning the credential's contents or its issuer's evidence. The identity circuit proves that a credential satisfies a predicate while revealing only the predicate's result. This complements the credential model in Trust and provenance: the credential stays with its holder, and the verifier learns only what it needs.

7. Verification on the network

7.1 Commitments through consensus

Verifying a STARK inside every EVM transaction would be expensive. Tenzro verifies proofs once and records the result:

1. A proof is submitted with its circuit identifier and public inputs.
2. Validators verify it natively.
3. A commitment to the proof, a hash over the circuit identifier, the proof bytes and the public inputs, is included among the validator-attested statements committed in the next checkpoint.
4. Once committed, the proof's commitment is part of certified state.

A commitment is open to challenge for a window after it is recorded. Anyone can file a fraud proof against an attested commitment, and a successful challenge removes the commitment.

7.2 Contracts

Contracts check proofs through the ZK_VERIFY precompile, which runs inside EVM transactions. Given a commitment, it answers whether the commitment is recorded, at the cost of a lookup rather than a full verification. A contract can therefore gate execution on a STARK: release escrow when a settlement proof is recorded, or admit a caller whose identity proof is recorded.

The trust model is explicit. A contract that calls ZK_VERIFY relies on consensus having verified the proof, as it relies on consensus for everything else in state.

7.3 Direct verification

Anyone can also verify a proof directly with the tenzro_verifyZkProof RPC method or the CLI:

tenzro zk verify \
  --circuit-id settlement \
  --proof 0x... \
  --inputs '["0x...","0x..."]'

Public inputs are field elements encoded as hex strings. The attestation and fraud-window record for a commitment can be read with tenzro zk attestation --commitment <hash>.

8. Proofs and trusted execution

Some computations need both privacy and verifiability. An enclave can produce the witness and run the prover inside an attested TEE, then sign the proof's commitment with a hybrid classical and ML-DSA-65 key. The verifier gets two independent kinds of evidence: the proof shows the computation was correct, and the attestation shows where it ran and that its inputs stayed sealed. Either can be checked without trusting the operator.

9. What Tenzro does not use proofs for

Proofs are not how Tenzro verifies inference. A proof about a computation says nothing about which model weights a provider actually served unless the weights themselves are bound into it, and proving a large model's forward pass is impractical. Tenzro verifies inference TEE-first:

• confidential inference runs inside attested TEEs, with attestation verified fully per vendor;
• every response carries a receipt signed by the operator, naming the model's manifest root;
• a receipt that contradicts the operator's signed policy is slashing evidence;
• disputed results can be challenged by re-execution.

See Trust and provenance.

10. Security considerations

• Soundness. Proofs rest on the collision resistance of the hash and the soundness of FRI under the published configuration. Configurations target proven soundness suitable for permanent evidence.
• Transparency. There is no trusted setup to compromise.
• Domain separation. Public inputs bind the chain, the circuit and the statement, so a proof cannot be replayed for a different chain, epoch or claim.
• Defence in depth. Compact certificates are always backed by raw certificates. Commitments are open to fraud proofs. A failure in proving delays compression, never consensus.

11. Conclusion

Tenzro uses Plonky3 STARKs where proofs earn their place: portable finality, compact settlement and private credential checks, all verified through consensus and callable from contracts. For hands-on detail, see ZK proofs and Finality certificates.