Frequently asked questions

What is Tenzro?

Tenzro is an open, permissionless, open-source (Apache 2.0) decentralised computing network for the Machine Economy. It provides networking, hardware-rooted security, payment rails and distribution layers for inference, training, distributed compute, data and storage, on a native settlement ledger with EVM, SVM and DAML runtimes and bridges to the major networks. It is designed for humans, agents and machines alike.

What is Tenzro Network 1?

Network 1 is the network that goes live on 1 October 2026 from a fresh genesis. It is a major upgrade over the testnet that ran earlier in 2026: a new post-quantum consensus protocol, keys rooted in hardware, trust and provenance for models and operators, a compute price index and metered settlement, inference for any model, training for agents, and an RPC that is closed by default. Accounts and balances from the testnet do not carry over. See Tenzro Network 1.

What is the Machine Economy?

Agents and machines buying and selling inference, compute, training, data and storage from each other, paying per use, with no human in the loop for each purchase. On Tenzro an agent can find a model, pay for a request in TNZO or stablecoins over HTTP 402, and settle on a chain whose keys live in hardware and whose finality is quantum-safe. See Machine Economy.

What is TNZO used for?

TNZO pays all network fees and transaction settlement: gas, inference, compute, storage and training. Operators stake it to take on roles, and it is used in governance. Supply is fixed at 1,000,000,000. Rewards come from a finite genesis pool rather than new issuance. An EIP-1559-style base fee is burned, with a split to the treasury. See Token economics.

Can I pay in stablecoins?

Yes. Stablecoin payments run through Bridge.xyz wallets, x402 and MPP, and gas can be paid in stablecoins through the same rails. Settlement happens on the Tenzro ledger. See Stablecoin payments.

Who can run a node?

Anyone. A home PC with a GPU, a homelab, an independent data centre or a neo-cloud can join. Roles include validator, RPC provider, AI (model) provider, compute provider, data and storage provider, security (TEE) provider and training provider. One node takes any set of roles under one identity, and one stake covers every role. Admission is permissionless: there is no allowlist and no approval step. See Operators and roles.

What hardware does a validator need?

Any machine with a TPM 2.0 can run a validator. Its signing keys are derived from the TPM on demand, used in memory and wiped, and votes are signed with a session key the hardware certifies once per epoch. See Validator lifecycle.

How does consensus work?

Tenzro DAG Consensus (TDC), our post-quantum consensus protocol. Every validator proposes in parallel each round, validator channels are keyed by X25519 plus ML-KEM-768, and finality certificates are signed with ML-DSA-65 and compressed with STARK proofs. See Consensus.

What is a finality certificate?

A proof, signed by validators holding a quorum of stake, that a checkpoint of the chain is final. Light clients, bridges and new nodes can carry one and check it themselves, and a validator that signs two conflicting checkpoints can be slashed with the two signatures as evidence. See Finality certificates.

Where are my keys?

In your hardware. Every key is rooted in a TPM 2.0, a Secure Enclave or a passkey. There are no key files and no seed phrases. Every passkey operation is a hybrid P-256 plus ML-DSA-65 signature, and passkeys require user verification. You can link more devices, and recover with a second passkey or with guardians under a timelock with a veto. See Hardware-rooted keys and Device linking and recovery.

How are agents identified and secured?

Each agent has its own DID. Machine DIDs are derived from the device key; an agent acting for a person holds a delegation scope and a spending policy that cap what it may do and spend. Agents talk to each other over A2A and to tools over MCP. See Agents and Identity.

How do payments work?

Paid resources answer HTTP 402 with a price. Clients pay with x402 or MPP, in TNZO or stablecoins, and retry. AP2 mandates let a person authorise an agent's purchase in advance, and the ACP buyer side lets agents check out from merchants. Settlement is metered per use by default, and everything settles on the Tenzro ledger. See Payments.

Which virtual machines are supported?

EVM, SVM and DAML. All three read one native TNZO balance, with an EVM, SVM and DAML view of the same amount, so there is no internal bridge. Tenzro precompiles run inside EVM transactions. See Multi-VM runtime.

What models can I serve or use?

Any open model the network's serving stack supports, across chat and reasoning, embeddings, vision, speech recognition and synthesis, image and video generation, detection, segmentation and forecasting. The catalogue is metadata, not an allowlist. Weights are stored across several origins and verified by hash. Browse the catalogue at Models and call models through the OpenAI-compatible APIs.

How is inference verified?

TEE-first. A provider running inside Intel TDX, AMD SEV-SNP, AWS Nitro or an NVIDIA confidential GPU produces attestation that is verified per vendor, and buyers can require it. Certification and ratings from issuers you trust add further evidence. See TEE.

What about other chains?

The ledger has bridges to the major networks, and bridges can check Tenzro finality certificates directly. See Bridge.

Who runs Tenzro?

No single company. The Tenzro Foundation, a non-profit, stewards the protocol and its Apache 2.0 code, the repositories, documentation and tools, and governs TNZO. The network works with individual developers, the open-source community and commercial partners such as Tenzro Labs, which helps operators onboard. Anyone can be an operator, developer or user. See Foundation.

How is the network upgraded?

Through on-chain governance: stake-weighted proposals, a timelock queue and execution. The validator set changes at epoch boundaries, and any staked node can join at the next boundary. Operators upgrade their binary in place: on start, a node checks its data against the configured genesis and refuses to start if they differ, so an upgrade never silently runs on the wrong chain. See Governance.

Where do I start?

Create a passkey wallet in the console, fund it by transferring TNZO to its address from another wallet or account, and follow Getting started. To run hardware, read Operators and roles.