Security claims are only useful with their limits attached. This post separates what is built from what is not, using the project's own documents: the cryptography reference, the post-quantum note, the list of known residuals and the threat model.
Context
Several protocols now let software agents pay for things: x402, AP2, ACP, MPP and card-network agent programmes among them. TRM Labs published an estimate that only a small share of x402 volume is agentic: it examined about 52.7 million US dollars of settlements and put the agentic share at between 0.6% and 7.5% of the volume left after screening, noting that a script and an agent leave the same onchain record. On the quantum side, Google announced a 2029 target for migrating its own systems to post-quantum cryptography in March 2026, as reported by QuSecure; the exact qubit estimates in the coverage vary, so none are repeated here. These are industry context. They are not claims about Tenzro or about adoption of it.
What is post-quantum today
Tenzro pairs a classical primitive with a post-quantum one, and for signatures both must verify. Validator votes, finality certificates and the channels between validators carry a post-quantum leg. Every account transaction needs an ML-DSA-65 signature beside the classical P-256 one, and an account with no ML-DSA-65 key enrolled signs nothing until it enrols one. Node-to-node transport offers only the X25519MLKEM768 hybrid. Key wraps for model keys, node credentials and session continuity use a hybrid X25519 and ML-KEM-768 envelope. Finality proofs default to STARKs, which rest on hash functions. See Cryptography.
The stated guarantee is narrow and conditional: a break of classical cryptography alone 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.
What remains classical
- Hardware attestation roots: TPM endorsement certificates, Secure Enclave attestations and TEE quotes are signed by vendors with RSA or ECDSA, which Tenzro cannot change.
- The P-256 leg of hardware keys, because TPM 2.0 and the Secure Enclave sign P-256 natively. The ML-DSA leg is derived from the same hardware root.
- External chains' own signatures, and EVM-standard transactions, which are verified by an external standard with secp256k1. Funds held only under a secp256k1 key are protected by secp256k1.
- Web certificates for browsers, agent HTTP signatures (RFC 9421), the optional Groth16 wrap of finality proofs, and the signature on release files.
Hardware-rooted machine identity
Account and node keys live in a TPM 2.0, a Secure Enclave or a passkey, and there is no software-key mode. A machine without a TPM delegates to another machine's TPM. That moves the trust to the machine holding the key, which is a limit, not a removal of one. See Hardware-rooted keys.
Agents with owners
An agent acting on the network is not anonymous. A delegated agent is recorded under its controller's identity, its authority is bounded by terms the controller signs, and revoking the controller or the delegation cascades to the agent and any child agents. A machine agent with no human controller roots in its own secure element and posts a bond that can be slashed. Owner-held limits and a kill switch are part of the design. See Agents.
Signed releases and provenance
Release archives come with a SHA-256 manifest signed by a hardware-held key, a software bill of materials and a build provenance statement, and you check them before installing as in Verify your download. The Linux x86_64 CPU archive was built twice on two hosts and the two builds are byte-identical.
Adversarial testing
The project runs checks against its own code: a daily advisory gate, nightly fuzzing of the decoders a peer can reach, per-merge review of which tests and Kani proofs a change puts at risk, bounded model-checking proofs for fee, supply, slashing and ledger arithmetic, and static rules. It also partitions, restarts and skews a private network on purpose, as described in Breaking our own network. Vulnerabilities are reported privately as set out in the repository's security policy.
What is not done
- No external security audit has been performed. The threat model says so. This post makes no claim of third-party assurance.
- Classical parts remain, as listed above, and some paths are post-quantum only from a governed time and classical before it. Block sync, state sync, gossip, blobs and inference requests authenticate with Ed25519 under the hybrid key exchange; the ML-DSA proof is not carried there yet. Some verifiers check the ML-DSA-65 leg only when the signing key has one.
- Known residuals in the project's list include: the participation roster at epoch close can differ on a node without that epoch's history and must be redesigned before mainnet; the record age rule has no activation gate for a later upgrade of a running network; batched records fail on a genesis with a faster calendar; the signing health flag is not a reliable alarm; and a restarted validator can stay outside the mesh for minutes under packet loss, with one four-validator stall unexplained because its logs were not kept. See the repository's
docs/KNOWN-RESIDUALS.md. - Release digests are not yet recorded in the chain registry; until that lands the digest in the release notes is the reference.
- The network is in preview and has not yet carried production use.
This is part of an economy for distributed compute and decentralized AI, open to machines of every size, from home nodes to data centers, working alongside centralized data centers. Security there is a set of properties to check and a list to keep honest, not a certificate.
