Security

Tenzro Network provides multi-layered security through hardware-backed trusted execution environments, zero-knowledge proofs, threshold MPC wallets, authenticated encryption, and on-chain compliance. This page provides an overview of each security layer with links to detailed documentation.

Security Layers

Trusted Execution Environments (TEE)

Hardware-backed confidential computing with Intel TDX, AMD SEV-SNP, AWS Nitro, and NVIDIA GPU CC. Real hardware attestation with X.509 certificate chain verification (pinned vendor root CAs), and AES-256-GCM enclave encryption with vendor-specific HKDF key derivation.

Crate: tenzro-tee (80 unit tests)

Zero-Knowledge Proofs

Groth16 SNARKs on BN254 via arkworks for inference verification, settlement proofs, and identity proofs. BGM17 MPC trusted setup ceremony with Phase 1 (Powers of Tau) and Phase 2 (circuit-specific CRS). Hybrid ZK-in-TEE execution for combining proofs with hardware attestation.

Crate: tenzro-zk (96 unit tests)

MPC Threshold Wallets

2-of-3 threshold wallets auto-provisioned without seed phrases. Argon2id-protected encrypted keystore (64MB memory, 3 iterations). Transaction validation with chain ID, nonce, gas bounds, and signature verification. Key material zeroized on drop.

Crate: tenzro-wallet (99 unit + 6 integration tests)

Cryptographic Primitives

Ed25519 and Secp256k1 key generation and signing, SHA-256 and Keccak-256 hashing, AES-256-GCM symmetric encryption, X25519 Diffie-Hellman key exchange, Shamir secret sharing over GF(256), and BLS12-381 aggregate signatures via blst.

Crate: tenzro-crypto (58 unit tests). All RNG uses OsRng (CSPRNG).

On-Chain Compliance (ERC-3643)

Regulated token compliance with KYC tiers, holder limits, freeze/unfreeze, and on-chain attestations for identity and accreditation verification.

Encrypted Messaging

End-to-end encrypted agent messaging using X25519 key exchange and AES-256-GCM. All inter-agent messages carry Ed25519/Secp256k1 signatures verified at the router level. Rate limiting (token bucket) at global, per-sender, and per-recipient scopes.

Consensus Security

HotStuff-2 BFT — Two-phase consensus with O(n) linear communication, tolerating up to f Byzantine validators where n >= 3f + 1
TEE-weighted validators — Validators with verified TEE attestation get 2x weight in leader selection
Equivocation detection — Double-vote detection wired into the vote collector, triggering 10% stake slashing via the StakingSlashingCallback
Peer authentication — ValidatorRegistry trait for peer authorization; consensus, block, and attestation topics are validator-only

Bridge Security

All cross-chain bridge messages support real Ed25519/Secp256k1 signing and verification via tenzro-crypto. Nonce-based replay protection prevents duplicate transfers. Bridge fees are quoted live from on-chain contracts (LayerZero EndpointV2, Chainlink Router, deBridge API, Canton Admin API) with static fallback.

Identity Security

The TDIP identity system provides:

Ed25519 credential signature verification with issuer key rotation support
Recursive trust-chain traversal with cycle detection, depth bounds, and trust-root anchoring
Delegation scope enforcement with typed DelegationViolation errors
KYC tier updates requiring signed VerifiableCredential proof
Cascading revocation broadcast across nodes with inbound revocation application
Credential nonce/replay protection via NonceRegistry
OAuth 2.1 + DPoP JWTs (RFC 9449 / RFC 9396) — decentralized network credentials minted by any node via tenzro_onboardHuman, tenzro_onboardDelegatedAgent, or tenzro_onboardAutonomousAgent. Each token is bound to a TDIP DID, an MPC wallet, and a holder Ed25519 key (RFC 7638 thumbprint in the cnf.jkt claim). Enables tiered access: read-only tools are public; write operations require a valid DPoP-bound JWT plus a per-request DPoP proof.
Token Exchange & Introspection (RFC 8693 / RFC 7662) — tenzro_exchangeToken mints a child JWT for a downstream agent with a strict subset of parent grants and AAP capabilities (controller_did chained for audit). tenzro_introspectToken follows RFC 7662 §2.2: invalid tokens return only {active: false} with no metadata leakage; valid tokens return the full claim set including DPoP cnf.jkt, RAR authorization_details, and AAP claims.
AS Metadata & Revocation (RFC 8414 / RFC 9728 / RFC 7009) — tenzro_oauthDiscovery exposes the issuer's AS metadata (also at /.well-known/openid-configuration) listing endpoints, supported grant types, and the AAP claim list. tenzro_revokeToken burns a token and cascades to all child tokens minted from it via Token Exchange — no central authority needed.
AAP profile (IETF draft-aap-oauth-profile-01) — seven aap_* claims (aap_agent, aap_task, aap_capabilities, aap_oversight, aap_delegation, aap_context, aap_audit) layer on top of RAR for agent provenance, human-oversight metadata, and EU AI Act Article 50 disclosures.

EU AI Act Article 50 — Disclosure & Provenance

Article 50 of the EU AI Act (effective 2026-08-02) imposes three obligations Tenzro implements at the protocol layer:

Art. 50(1) — chatbot disclosure. Inference responses from agents acting under autonomous or delegated AAP scopes carry an explicit aap_agent claim in the access token, surfaced to clients alongside the response. End users and downstream auditors can always determine they are interacting with an AI system, not a human.
Art. 50(2) — synthetic content marking. Every AI-generated artifact (text, image, audio, video) emitted by a Tenzro inference provider is bound to a C2PA-style ProvenanceManifest keyed by SHA-256(content_bytes). The manifest records the model id, provider DID, generation timestamp, and is signed by the validator's Ed25519 block-signing key — the same root of trust that signs blocks.
Art. 50(4) — deepfake labeling. Image/audio/video providers set is_synthetic = true and generation_kind in the manifest. Verifiers downstream can distinguish "AI-altered" from "AI-generated" without trusting the provider's metadata in isolation.

Read RPC: tenzro_getProvenance { content_hash } returns the full ProvenanceManifest for any artifact previously seen by the network. Manifests are gossiped on validator-only topics and persisted alongside block state — a missing manifest means an artifact was not produced by a registered Tenzro provider.

← Architecture Next: TEE Security →