Cryptography

Tenzro Network pairs classical and post-quantum cryptography. Validator votes, finality certificates and the channels between nodes carry a post-quantum leg, and every account transaction needs an ML-DSA-65 signature beside the classical one. The classical algorithms stay alongside the post-quantum ones, so an attacker has to break both, and the classical parts are named.

The guarantee: a break of classical cryptography alone (ECDSA over secp256k1 or P-256, Ed25519, X25519) cannot forge a validator vote or certificate, move funds from a Tenzro account, forge a bridge committee attestation, or read a protected secret that Tenzro wraps. It holds while the post-quantum primitive of each path holds; breaking both legs of a path breaks the path. The exceptions are places where the verifier is someone else's, listed below.

Primitives

Composite hybrid signatures

A Tenzro signature is one composite object with two legs: a classical signature (P-256 from a passkey, TPM or Secure Enclave, or Ed25519) and an ML-DSA-65 signature. It follows the IETF composite ML-DSA construction:

• Both legs are required. A verifier accepts the signature only if both legs verify; there is no classical-only and no post-quantum-only path. An account with no ML-DSA-65 key enrolled signs nothing until it enrols one.
• Non-separable. Both legs sign a message that is bound to the composite: to the pairing of the two public keys and to a domain label for the construction. A leg lifted out of a composite signature does not verify as a stand-alone signature, and cannot be recombined with a different partner.
• Bound to the account. The ML-DSA-65 public key used for transactions is part of the account's identity. A transaction's hash commits to the sender's post-quantum key, and the network checks that this key belongs to the sending account. A valid ML-DSA-65 signature from any other key is rejected.

The same construction covers passkey operations (P-256 + ML-DSA-65), validator handshakes (P-256 + ML-DSA-65, signed by the validator's hardware key) and guardian approvals.

Accounts

The ML-DSA-65 leg of an account transaction is mandatory. An account has no ML-DSA-65 key until it enrols one, and its first transaction is the enrollment, verified against the key it enrols. After that, a transaction with a P-256 leg alone is refused at admission and at execution, whether or not a key is enrolled.

• Enrol with the CLI. tenzro pq-hybrid enroll enrols the hardware ML-DSA-65 key as the client account's post-quantum key. The CLI also enrols automatically before the first transaction a new account sends.
• Enrol with an SDK. sendEnrolling in the TypeScript SDK, and send_enrolling in the Rust and Python SDKs, send the first transaction as the enrollment.
• Other keys acting for the account. The governed lever accounts.ml_dsa_leg_on_enrolment.status decides whether an account that enrols a key requires the ML-DSA-65 leg from then on of every key acting for it: its own key, linked passkeys and recovery signers. It is paused at genesis, and a vote enables it. See Governed parameters.
• Payments and approvals. Payment authorizations, escrow vouchers, payer signatures, settlement preferences, owner-signed RPC actions, the smart-account validators and the root approvals of agent terms need the ML-DSA-65 leg too.
• Identity. Registering an identity is refused for hardware that cannot produce an ML-DSA-65 key, and a node's DID document lists its ML-DSA-65 method first. KERI logs take ML-DSA-65 keys by default.

Post-quantum coverage

What stays classical

Where the verifier is someone else's, or the key lives in hardware with no post-quantum operation, a classical primitive remains. These are the places:

• Hardware attestation roots. A TPM endorsement certificate, a Secure Enclave attestation and a TEE quote are signed by the vendor with RSA or ECDSA, and Tenzro cannot change the vendor's algorithm. They bind a machine to a key; the key's use on Tenzro is hybrid.
• The P-256 leg of hardware keys. TPM 2.0 and the Secure Enclave sign P-256 natively. The ML-DSA leg is derived from the same hardware root, and the pairing is what makes the pair safe.
• External chains' own signatures. Tenzro's acceptance of a bridge delivery is post-quantum, but the external chain's finality is not Tenzro's to change. A classical ceiling bounds what a forged source chain can mint, and outbound records and handovers are verified by contracts on those chains with secp256k1.
• EVM-standard transactions. A transaction type defined by an external standard is verified by that standard with secp256k1. Funds at an address controlled only by a secp256k1 key are protected by secp256k1; a holder who wants the guarantee uses a native account.
• Web certificates. RPC and MCP endpoints presented to browsers use classical certificates; the key exchange offered first is hybrid. Relay HTTPS and address lookup keep X25519 as a fallback.
• Groth16 wrap. The optional Groth16 wrap of finality proofs for external chains rests on a pairing assumption and is labeled classical. The STARK is the default form.
• Release signing and published checksums. Releases are signed with a hardware key through the toolchain. See Verify your download.
• Agent HTTP signatures (RFC 9421), verified by parties outside Tenzro, use P-256 held in the serving machine's TPM.

Some paths are post-quantum only from a governed time, and classical before it: machine records need the ML-DSA-65 leg from records.pq_leg_required_from_ms, and stored records need hybrid session signatures from session.hybrid_records_from_ms. Both are set by governance and default to never.

Open items that need a consensus rule or a guest-program change:

• Duty handover proofs take a Groth16 seal, and the TEE attestation of a finality proof binds a Groth16 wrap. A STARK form needs a rule or a rebuilt guest.
• Block sync, state sync, gossip, blobs and inference requests authenticate with Ed25519 under the hybrid key exchange; they have no versioned protocol yet that carries the ML-DSA proof.
• Evidence of a wrong committee handover checks only the secp256k1 signature the external contract verifies, so closing it needs a handover format that carries both legs.
• Some verifiers check the ML-DSA-65 leg only when the signing key has one, so a key with no enrolled ML-DSA-65 key is still accepted there: sensor evidence device signatures, usage records of metered bonds, reserve attestations, signed sealed-model manifests, identity envelopes, session certificates, the operator binding in trust policy, the admin audit log and the read-only tenzro_verifySignature.
• A node DID document lists its ML-DSA-65 method, but its own proof is a P-256 Data Integrity proof by the machine key; the document carries no ML-DSA-65 signature of its own.

Where keys come from

Classical keys live in hardware: a passkey authenticator, a TPM 2.0 or a Secure Enclave. The ML-DSA-65 key that pairs with each one is derived from the same hardware root when it is needed, used in memory and wiped. Nothing that can sign is kept in a file. See Hardware-rooted keys.

Consensus

Tenzro DAG Consensus (TDC), our post-quantum consensus protocol, uses these primitives throughout:

• Channels. Validator-to-validator channels are keyed with a hybrid of X25519 and ML-KEM-768. The handshake is signed by each validator's hardware key with a composite ML-DSA-65 + P-256 signature.
• Votes. Validators sign votes with an in-memory session key that their TPM certifies once per epoch.
• Finality certificates are signed with ML-DSA-65. They are portable: a light client, a bridge or a new node can check them, and they are the evidence used to slash double-signing.
• Compact certificates. Compact finality certificates are wired, and light clients verify them every epoch.

See Consensus and Finality certificates.

Encryption

Key agreement is hybrid wherever a long-lived secret is at stake: an X25519 exchange and an ML-KEM-768 encapsulation are combined through HKDF-SHA256, and the result keys AES-256-GCM. Key wraps use envelope version 2, the same hybrid, so reading a wrapped value needs both exchanges broken. Transport uses the TLS 1.3 X25519MLKEM768 group. Raw X25519 output never keys a cipher directly, and envelope encryption binds the derivation to both the sender's ephemeral key and the recipient's key, so an exchange cannot be replayed against a different recipient. See Secure messaging.

STARKs

Tenzro uses Plonky3 STARKs for proofs that must be cheap to verify: compressed finality certificates, settlement proofs and identity proofs. STARKs rely only on hash functions, so they need no trusted setup and stay sound against quantum attackers. See Zero-knowledge proofs.

Inference is verified with TEE attestation, not with STARKs. See TEE.

Verifiable randomness

Where the network needs unbiased randomness it uses an RFC 9381 VRF, whose output anyone can check against the prover's public key. See VRF.

Tools

The CLI verifies signatures and VRF proofs without touching a key:

tenzro crypto verify --key 0x<public-key> --message 0x<message> --signature 0x<signature> \
  --key-type ed25519
tenzro vrf verify --pubkey 0x<public-key> --alpha 0x<input> --proof 0x<proof>

The JSON-RPC equivalents are tenzro_verifySignature and tenzro_verifyVrfProof.

Signing is done by your hardware-rooted signer, never by passing a private key on the command line. See Hardware signer SDK.

The open method tenzro_verifySignature checks a signature against a public key over JSON-RPC.