Security

Tenzro Network is built so that the things that matter most (keys, finality, money and data) are protected by hardware and by post-quantum cryptography, and so that nothing is reachable unless someone deliberately made it so. This page summarises the model. Each section links to the page with the details.

Keys: rooted in hardware

Every key on the network is rooted in a TPM 2.0, a Secure Enclave or a passkey. There are no key files and no seed phrases to steal.

• People hold passkeys. Every passkey operation requires user verification and is a hybrid P-256 plus ML-DSA-65 signature. Synced passkeys are accepted at a lower tier and are never the sole root of an account.
• Machines hold device keys. A node's signing keys are derived from its TPM or Secure Enclave on demand, used in memory and wiped. Human DIDs are derived from the passkey, machine DIDs from the device key.
• Accounts survive the loss of a device: link more devices, and recover through a second passkey or through guardians, with a timelock and a veto for the owner.

See Hardware-rooted keys and Device linking and recovery.

Signatures: quantum-safe by construction

Transactions carry a composite hybrid signature in the style of the IETF composite ML-DSA construction: a classical signature and an ML-DSA-65 signature over the same message, verified together and not separable. The post-quantum key is bound to the account, so an attacker cannot strip or swap it. See Cryptography.

Consensus and finality

Tenzro DAG Consensus (TDC), our post-quantum consensus protocol, orders and finalises blocks.

• Validators talk over channels keyed with X25519 plus ML-KEM-768. Each handshake is signed by the validator's hardware key (ML-DSA-65 plus P-256), so a channel cannot be opened by anyone who does not hold that hardware.
• Consensus votes are signed with an in-memory session key that the validator's hardware certifies once per epoch.
• Finality certificates are signed with ML-DSA-65. Compact finality certificates are wired, and light clients, bridges and new nodes verify them every epoch; a pair of conflicting signed certificates is proof of double-signing.
• Double-signing and other provable faults are slashed, and slashing burns the offender's bond.

See Consensus, Finality certificates and Slashing.

RPC: closed by default

Every node method is classified, and anything unclassified is refused. Reads are open. Anything that moves money or changes state needs a signature from the paying account; the operator of the node cannot act for you. Operator policy on a node needs that node's admin token and cannot change network-wide state. Node listeners bind to loopback until the operator exposes them. See RPC access.

TEEs: evidence, not custody

Trusted execution environments give evidence about where and how a workload ran. Attestations from Intel TDX, AMD SEV-SNP, AWS Nitro and NVIDIA confidential GPUs are fully verified against each vendor's chain of trust. TEEs never hold user keys and never weight consensus. Inference verification is TEE-first. See TEE.

Proofs

Zero-knowledge proofs use Plonky3 STARKs: hash-based, with no trusted setup. See ZK.

Operators, models and data

• Operators publish signed policies and are slashed only for provable breaches of their own policy. See Operator policies.
• Model weights are stored across several origins and verified against their published hashes before they load. See Model provenance.
• Certification and ratings for models and operators can come from any issuer, and each relying party chooses which issuers it trusts. See Trust and provenance.
• Every surface of a node is governed by its access policy, which can only refuse. Files belong to the DID that uploaded them, and other callers cannot list or read them. Storage claims carry bonded SLAs. See RPC access and Decentralised storage.

Running a node safely

• Expose only the ports your roles need; keep metrics private.
• Administer the node with a DPoP-bound access token signed in from its hardware key or your passkey; there are no admin tokens or shared secrets to leak.
• Make a node private with its visibility, and name customers and their rate tiers in its access policy.
• Run the same release as the network and upgrade promptly.

The full checklist is in Deployment.

Report a vulnerability

If you find a security issue in the network, the node software, the SDKs, the CLI or this website, please tell us privately first.

• Email eng@tenzro.com, or
• use GitHub private vulnerability reporting on the affected repository in the tenzro organisation.

Include what you found, how to reproduce it and the impact you expect. We will acknowledge your report and work with you on the fix and its disclosure. Please do not disclose the issue publicly, or test against other people's accounts or nodes, until a fix is available. More at Security.