Skip to content
Tenzro
Launching 1 October 2026

Tenzro Network 1

The network where machines transact with each other safely. Network 1 ties every payment, model and operator to hardware-rooted keys, verifiable provenance and post-quantum finality. It is a major upgrade over the testnet that ran earlier this year, rebuilt from the consensus up and started from a fresh genesis.
Overview

The full stack for the Machine Economy.

Networking, hardware-rooted security, payment rails, and distribution layers for inference, training, compute, data and storage, on a native settlement ledger that runs EVM, SVM and DAML and bridges to the major networks. Anyone can run it, build on it or use it.
  1. Participants
    • Humans
    • Agents
    • Machines
  2. Services
  3. Rails
  4. Settlement
  5. Consensus
  6. Hardware
    • TPM 2.0
    • Secure Enclave
    • Passkeys
    • TEEs
    • GPUs
One network, one stake, one settlement layer. Every layer is open source under Apache 2.0.
Why now

What changed, and why we rebuilt.

  • A stolen key is spent at machine speed

    Agents now hold spending authority and act without a person in the loop. Keys have to live in hardware, and spending has to carry limits the network enforces.
  • Signatures recorded today can be forged later

    Long-lived agent credentials, bridges and payments cannot wait for the day quantum computers arrive. Finality has to be quantum-safe now.
  • Trust in AI needs evidence

    Who served this model, which weights, under which policy, certified by whom. Relying parties need to pick the issuers they trust and check the rest themselves.
01

Tenzro DAG Consensus (TDC)

Our post-quantum consensus protocol. Every validator proposes in parallel each round, so no single leader limits the network.

  • A DAG design: every validator proposes in parallel each round, so throughput is not bound to one leader.
  • Post-quantum from the wire up. Validators talk over channels keyed by X25519 and ML-KEM-768, with a handshake signed by each validator's hardware key using ML-DSA-65 and P-256.
  • Finality certificates are signed with ML-DSA-65. Light clients, bridges and new nodes can carry them and check them, and they can be used to slash a validator that signs two conflicting checkpoints.
  • Certificates are compressed with STARK proofs.
  • Consensus uses no signature scheme that a quantum computer can break.
02

Keys that live in hardware

Every key is rooted in a TPM, a Secure Enclave or a passkey. There are no key files and no seed phrases.

  • Every key is rooted in a TPM 2.0, a Secure Enclave or a passkey.
  • Any TPM 2.0 machine can run a validator. Signing keys are derived from the hardware on demand, used in memory and wiped.
  • Votes are signed with an in-memory session key that the hardware certifies once per epoch, so the hardware is never on the hot path.
  • People sign in with passkeys. Their identity is derived from the passkey itself, and every passkey operation carries a post-quantum ML-DSA-65 signature alongside P-256.
  • Add more devices, or guardians, so losing one device never means losing the account.
03

Trust and provenance

Certification and ratings for models and operators, issued by anyone. You choose which issuers you trust and check the rest yourself.

  • Any party can certify or rate a model or an operator. Relying parties choose the issuers they trust.
  • Operators publish signed policies, and are slashed only for provable breaches of their own policy.
  • Model weights are stored across multiple origins and verified by hash.
  • Compliance tiers come from trust credentials, not a central registry.
  • Trusted execution environments provide evidence that a workload ran untouched, verified against each hardware vendor's attestation chain.
04

The Machine Economy

A compute price index in consensus, SLA-attested rentals and metered, per-use settlement, paid in TNZO or stablecoins.

  • A compute price index committed to consensus, built from metered usage.
  • Compute claims, and SLA attestation, with rental billing on the chain's verdict.
  • Metered settlement by default: agents pay per use.
  • Stablecoin payments on Bridge.xyz wallets, x402 and MPP, including gas paid in stablecoins through the same rails.
  • An ACP buyer side, so agents can purchase through agent-commerce flows.
05

Inference for any model

Prefix and state reuse for every architecture class, behind OpenAI-compatible APIs for chat, embeddings, images, audio and video.

  • Prefix and state reuse for every architecture class: dense, sliding-window, hybrid recurrent and state-space, mixture-of-experts, multimodal and media models.
  • OpenAI-compatible APIs for chat, embeddings, images, audio and video.
  • Requests route to providers you can filter by trust, price and location.
06

Training for agents

Decentralised training with a chat fine-tuning objective for agent trajectories. Every round can be replayed from its seed.

  • Decentralised training across operators and clusters.
  • A chat fine-tuning objective built for agent trajectories.
  • Every training round can be replayed from its seed, so contributions can be checked.
07

Closed by default

Open, owner and admin methods are separate. Anything that moves money or changes state needs a signature from the account that pays.

  • The RPC surface is split into open, owner and admin methods.
  • Anything that moves money or changes state requires a signature from the account that pays.
  • Hosted functions and skills run deny-by-default, and databases are isolated per tenant.