Hardware-rooted keys

Every key on Tenzro Network 1 is rooted in hardware: a TPM 2.0, an Apple Secure Enclave or a passkey. That covers people signing in, agents paying for inference, providers serving models and validators voting on blocks. There are no key files to copy or leak, and no seed phrase to write down.

The two roots

An identity is rooted in exactly one of two things.

A machine without a usable TPM or Secure Enclave has no identity of its own. It runs under the delegated authority of the person who owns it, so its root is that person's passkey. Tenzro never falls back to a random key written to disk: if the hardware root is missing, the node refuses to start as something weaker.

Agents are machines. An agent that runs on a TPM-equipped server, or on a Mac with a Secure Enclave, holds a machine DID derived from that device's key. An agent acting for a person holds a machine DID under that person's human DID and a delegation scope that caps what it can do. See Identity.

How a key is used

Hardware-rooted keys follow one rule: derive on demand, use in memory, wipe.

1. When a signature is needed, the key is derived from the hardware root: the TPM or Secure Enclave produces it, or the passkey releases it after user verification.
2. The key signs in process memory, for that one operation or ceremony.
3. The key material is zeroed as soon as the operation finishes.

Nothing that can sign is ever written to disk, and nothing that can sign is ever sent to a node. Because the derivation is deterministic, the same hardware always produces the same key: reinstalling the software, wiping the data directory or reinstalling the operating system does not change a machine's identity.

Hybrid by default

Every hardware-rooted signature on Network 1 is hybrid: a classical leg plus an ML-DSA-65 post-quantum leg.

• Passkeys sign with P-256 inside the authenticator. The ML-DSA-65 key for the same credential is derived from the passkey on demand, used for that ceremony and wiped. Each device credential has its own ML-DSA-65 key; nothing is stored.
• TPM 2.0 and Secure Enclave keys sign with P-256 in the hardware. The companion ML-DSA-65 key is derived from the hardware root on demand, in the same way.

The two legs form one composite signature that is bound to the account. Neither leg is accepted on its own, and a leg cannot be lifted out and reused elsewhere. See Cryptography.

Validators and operators

Any machine with a TPM 2.0 can run a validator. The validator's identity key is rooted in the TPM, and its consensus keys follow from it.

• Session keys per epoch. At each epoch boundary the TPM certifies a fresh in-memory session key. The validator signs its votes with that session key for the epoch, so the hardware is asked once per epoch rather than once per vote. The session key lives only in memory and is wiped when the epoch ends.
• Channel handshakes. Validator-to-validator channels are keyed with X25519 + ML-KEM-768, and each handshake is signed by the validator's hardware key (ML-DSA-65 + P-256). See Networking.
• Finality certificates are signed with ML-DSA-65 and can be checked by light clients, bridges and new nodes. See Finality certificates.

Model, compute, storage, TEE and training providers use the same machine identity. The operator's DID is what certifications, ratings and signed operator policies attach to. See Trust and provenance.

Choose how a machine is operated when you set it up:

# A person holds the passkey that controls this machine
tenzro setup --operator self

# The machine answers for itself through its TPM 2.0 or Secure Enclave
tenzro setup --operator autonomous --mode validate --roles validator

--operator autonomous requires a usable TPM 2.0 or, on Apple hardware, a Secure Enclave. See Validator lifecycle for the rest of the validator flow.

People

A person creates an account by creating a passkey in the console, or in any application built with tenzro-sdk.

• User verification (fingerprint, face or device PIN) is required for every signature.
• A device-bound passkey is the strongest human root. A synced passkey, one that a platform copies between devices, is accepted at a lower tier and can never be an account's only root.
• An account should always have a second root: another device's passkey, or a set of guardians. See Device linking and recovery.

See Console and passkey wallet.

What a TEE is for

Trusted execution environments (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA confidential GPUs) produce evidence: an attestation that a given workload ran on genuine hardware in a given state. Network 1 verifies that evidence in full for each vendor. A TEE is not where keys are kept, and no account depends on a TEE to sign. See TEE.

Summary