Tenzro Network 1

Abstract

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

In one line: Network 1 is the post-quantum network for autonomous AI. Agents buy inference, compute and training, pay in stablecoins, and settle on a chain whose keys are rooted in hardware and whose finality is quantum-safe.

This paper describes the motivation for the network, the seven pillars of its design, the participants who supply and consume its resources, how value settles, the role of the TNZO token, and how the network is governed. Companion papers specify each pillar in depth: Tenzro DAG Consensus, Hardware-rooted identity, Trust and provenance, Settlement for the Machine Economy, Tenzro Train, TNZO and Proofs on Tenzro.

1. Introduction

Tenzro Network 1 launches on 1 October 2026 from a fresh genesis. It is a major upgrade over the testnet that ran earlier in 2026: a new consensus protocol, a new key model, a trust layer for models and operators, and a settlement layer designed around metered, per-use payment.

The network is stewarded by the Tenzro Foundation, a non-profit. Anyone can run a node, serve resources, build on the network or use it. There is no allow-list for operators and no privileged issuer of trust.

2. Motivation: the Machine Economy

A growing share of economic activity is carried out by software acting on its own: agents that fetch quotes, call models, rent GPUs, buy data, pay for storage and settle with each other. We call this the Machine Economy. It changes three assumptions that most existing infrastructure was built on.

2.1 Spending authority without a human in the loop

An agent with a budget acts at machine speed. A stolen key or a forged approval is spent before anyone notices, so the cost of a key compromise is higher than it was when a person approved each payment. Keys must be rooted in hardware, authority must be scoped and time-bounded, and anything that moves money must carry a signature from the account that pays.

2.2 Long-lived records in a post-quantum world

Signatures and certificates recorded today may be forged later by an adversary with a large quantum computer. A network that settles long-lived agent credentials, bridge messages and payment records cannot wait until that day to change its cryptography. Network 1 is post-quantum from the wire up: validator channels, finality certificates and account signatures all carry a post-quantum leg.

2.3 Trust in AI needs evidence

A buyer of inference wants to know who served the request, which weights answered it, under which policy, and who vouches for the model and the operator. Claims are not enough. Relying parties need signed, checkable evidence, and they need to choose for themselves which issuers of that evidence they trust.

2.4 Supply is everywhere

Useful hardware sits in home PCs with a GPU, homelabs, independent data centres of every size, neo-clouds and existing data-centre fleets. Most of it is idle some of the time. The Machine Economy needs a neutral way for that hardware to be discovered, priced, verified and paid, without a single company in the middle.

Network 1 is designed from the ground up for these conditions.

3. Design goals

• Open and permissionless. Anyone can operate, build or use. The protocol privileges no operator, issuer or vendor.
• Hardware-rooted. Every key is rooted in a TPM 2.0, a Secure Enclave or a passkey. There are no key files and no seed phrases.
• Quantum-safe finality. Consensus channels and finality certificates use post-quantum cryptography.
• Evidence over claims. Models, operators and services are judged by signed credentials, receipts and attestations.
• Metered by default. Machines pay per use, in TNZO or stablecoins, and settle on the chain's verdict.
• Closed by default. The RPC surface is split into open, owner and admin methods. Anything that moves money or changes state needs a signature from the paying account.
• One stack. Networking, identity, payments, inference, training, compute, storage and settlement share one identity and one ledger.

4. The seven pillars

4.1 Tenzro DAG Consensus

Tenzro DAG Consensus (TDC) is our post-quantum consensus protocol. It is a DAG-based Byzantine fault tolerant protocol for n = 3f + 1 validators by stake.

Every validator proposes in parallel each round. Each round, every validator broadcasts a vertex that references a quorum of vertices from the previous round and carries batches of transactions. No single leader limits how much the network can carry. A designated leader vertex per round anchors the order: once a quorum of the next round references it, it commits, and its causal history is ordered deterministically into a block.

Validators talk over channels keyed by a hybrid key exchange of X25519 and ML-KEM-768. Each channel handshake is signed by the validator's hardware-rooted key, a composite of ML-DSA-65 and P-256. Messages on the channel are authenticated with symmetric keys derived from that handshake.

On top of ordering, validators vote on periodic checkpoints. A quorum of ML-DSA-65 votes forms a finality certificate. Certificates are portable: light clients, bridges and new nodes can carry and check them without trusting anyone. Two conflicting votes from the same validator are transferable evidence for slashing. Certificates are compressed with STARK proofs so they are cheaper to carry and verify. Consensus uses no pairing-based aggregate signatures.

See Tenzro DAG Consensus.

4.2 Hardware-rooted keys

Every key on the network is rooted in a TPM 2.0, a Secure Enclave or a passkey. Humans hold passkeys on their devices. Machines hold keys rooted in their TPM or Secure Enclave.

Any TPM 2.0 machine can run a validator. Signing keys are derived from the hardware on demand, used in memory and wiped. Consensus 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 of consensus.

A human's DID is derived from their passkey. A machine's DID is derived from its device key. Every passkey operation is a hybrid P-256 and ML-DSA-65 signature in a composite, non-separable construction, and the post-quantum key is bound to the account. Users link more devices and recover with a second passkey, or with guardians behind a timelock that any existing device can veto.

See Hardware-rooted identity.

4.3 Trust and provenance

Anyone can issue a certification or rating for a model or an operator: a regulator, a standards body, an auditor, a community or a model's creator. Relying parties choose the issuers they recognise; nobody else can change that choice.

Operators publish signed, machine-readable policies that state what they serve and refuse. They are slashed only for provable breaches of their own policy, evidenced by their own signed receipts. Model weights are identified by a hash over every file, stored across multiple origins and verified by hash on download. Compliance tiers come from trust credentials, not from a central registry.

Trusted execution environments (Intel TDX, AMD SEV-SNP, AWS Nitro and NVIDIA confidential GPUs) are evidence, not custody. Attestation is verified fully for each vendor and feeds routing and credentials.

See Trust and provenance.

4.4 The Machine Economy

Network 1 settles machine-to-machine commerce directly:

• A compute price index, built from metered and attested usage, is committed to consensus.
• Compute claims are standardised claims on capacity, delivered by the provider or settled against the index.
• SLA attestation lets the chain decide whether a provider delivered. Rental billing follows the chain's verdict.
• Metered, per-use settlement is the default. Agents pay per request, per token or per unit of time.
• Stablecoin payments run through Bridge.xyz wallets, x402 and MPP, including gas paid in stablecoins.
• Agents buy from merchants through the ACP buyer side, and act under AP2 mandates.

See Settlement for the Machine Economy.

4.5 Inference for any model

Providers serve open-weight models of any architecture on their own hardware. Prefix and state reuse works for every architecture class: dense, sliding-window, hybrid recurrent and state-space, mixture-of-experts, multimodal and media models. Models too large for one machine are served across a LAN cluster or as distributed expert shards.

Applications reach models through OpenAI-compatible APIs for chat, embeddings, images, audio and video at https://rpc.tenzro.xyz. They authenticate with an API key in the X-Tenzro-Api-Key header, or pay per request with HTTP 402 through x402 or MPP. Confidential inference runs inside attested TEEs, and inference verification is TEE-first.

See Inference and OpenAI-compatible APIs.

4.6 Training for agents

Tenzro Train coordinates decentralised training over independent hardware. Trainers run an inner loop locally and exchange compressed outer gradients each round; a committee of syncers aggregates them under a rule chosen for the run's trust tier. A chat fine-tuning objective trains models on agent trajectories, with the loss on assistant turns and tool calls. Every round is replayable from its seed, so anyone can recompute what a round should have produced.

See Tenzro Train.

4.7 Closed by default

The RPC surface is split into three classes:

Anything that moves money or changes state requires a signature from the paying account. A node's own operator cannot move a user's funds or change a user's identity. Every method's class is discoverable with tenzro_listRpcMethods.

See RPC access.

5. Architecture

5.1 One node, many roles

The network runs one node binary, tenzro-node, and one CLI, tenzro. A node takes any set of roles under one identity: validator, full node, AI (model) provider, compute (GPU) provider, storage and database provider, TEE provider, trainer and syncer, edge, archive and bootstrap. Each role carries a bond on a governance-adjustable ladder. An unbonded node may sync and relay but carries no quorum weight.

5.2 Networking

Peers discover each other over a Kademlia DHT and propagate transactions, provider announcements and agent traffic over gossip topics. Consensus traffic runs on the authenticated post-quantum validator channels described above. Community nodes behind NAT reach the network through relays and hole punching. Content-addressed data, model files and training payloads move over QUIC with verified streaming, so every chunk is checked against its hash as it arrives.

5.3 The ledger

The ledger executes three runtimes over one state:

• EVM, with the standard precompiles plus Tenzro precompiles that run inside EVM transactions, for example attestation verification (TEE_VERIFY), proof verification (ZK_VERIFY) and verifiable randomness (VRF_VERIFY). ERC-4337 account abstraction, ERC-7579 modular validators, EIP-7702 and Permit2 are supported.
• SVM, where Solana programs run and SPL tokens map onto the native token registry.
• DAML, for multi-party workflows through the Canton JSON Ledger API.

There is one native TNZO balance per account, with EVM, SVM and DAML views of it. There is nothing to wrap or bridge between runtimes. Execution uses Block-STM parallel execution, and block time is deterministic: each block's timestamp is derived from timestamps attested by a quorum of validators. Fees follow an EIP-1559-style base fee.

Bridges connect Network 1 to the major networks. Cross-chain requests use ERC-7683 intents, so a user states the outcome and the network routes it. Bridges and light clients rely on certified finality.

5.4 Agent surfaces

Agents reach the network over JSON-RPC, over MCP at https://mcp.tenzro.xyz/mcp and over A2A at https://a2a.tenzro.xyz. MCP uses Streamable HTTP with OAuth 2.1 and DPoP. A2A publishes an Agent Card at /.well-known/agent.json. Agent identities can be mirrored to ERC-8004 registries so they are recognisable on other chains.

5.5 Data, storage and hosting

Storage providers hold content-addressed, erasure-coded data and are paid per byte-epoch only when a proof of retrievability passes. Storage is backed by bonded SLAs: a missed proof feeds slashing and re-replication. Databases are isolated per tenant. Hosted functions are deny-by-default and receive only the capabilities their owner grants.

6. Participants

6.1 Supply side

Operators are machine owners who monetise hardware: a home PC with a GPU, hobbyists and homelabs, independent data centres, neo-clouds and existing data-centre operators distributing their compute or models. Their roles are:

• Validators, who order transactions and sign finality certificates.
• RPC providers, who serve public or gated endpoints and issue tenant API keys.
• AI (model) providers, who serve inference.
• Compute (GPU) providers, who rent capacity.
• Data and storage providers, who hold data and databases.
• Security (TEE) providers, who serve attested confidential compute.
• Training providers, who run trainers and syncers.

Technical support and go-to-market partners help operators of every background onboard. Tenzro Labs is one such commercial partner.

6.2 Demand side

• Developers building AI-native applications who want open frontier models, custom pricing and alternatives to hyperscalers and large labs.
• Organisations in regulated industries that need transparency and control over models, data and compute residency.
• Privacy-conscious developers and organisations with sensitive workloads.
• Model developers and researchers who need compute and distributed training.
• Agents and machines that buy inference and compute on their own account.

6.3 One identity for all

Every participant, human or machine, has a DID derived from a hardware-rooted key and a wallet bound to it. The same identity signs transactions, holds credentials, receives payments and is named in receipts.

7. Settlement

Settlement is where the pillars meet. A typical agent request runs as follows:

1. The agent discovers providers and their prices, filtered by the trust list the agent's owner chose.
2. The provider's endpoint answers with an HTTP 402 challenge, or the agent opens a metered session.
3. The agent pays under its mandate and scope, in TNZO or a stablecoin, signed by its hardware-rooted key.
4. The provider serves the request and signs a receipt naming the model's manifest root and the metered usage.
5. The payment is settled on the ledger. The settled amount is divided between the operator, the treasury and, where the serving node does not validate, the RPC provider that validates on its behalf.
6. Receipts feed the compute price index, the provider's reputation and, where a policy or SLA was breached, slashing evidence.

Escrow, micropayment channels, streaming escrow and batch settlement cover the different shapes of work. See Settlement for the Machine Economy.

8. TNZO

TNZO is the network's token. It pays all network fees and transaction settlement, and it is what operators bond and what governance votes in.

• Supply is fixed at 1,000,000,000 TNZO, with 18 decimals.
• Rewards come from a finite pool set at genesis. They are not minted.
• Fees follow an EIP-1559-style base fee, split between burn and treasury. Priority fees go to validators.
• Staking and provider bonds have a 7-day unbonding period.
• Slashing burns the offender's bond.
• Payers may fund gas in stablecoins through the same payment rails; network fees are accounted in TNZO.

See TNZO.

9. Governance

The Tenzro Foundation is the non-profit steward of the network. It maintains the protocol and network primitives under Apache 2.0, the repositories, documentation and tools, distributes and markets network resources, and is the governing body for TNZO.

Protocol parameters, treasury disbursements and upgrades are decided by stake-weighted on-chain voting, with delegation. Each proposal class has its own quorum, voting window and timelock, matched to its risk. The governance surface is the same whether the voter is a person, a delegated agent or an autonomous agent.

The network is built with partners and developers: individual developers and the open-source community, and commercial partners that help operators onboard. Tools are built by the Foundation, independent developers and partners, including abstraction layers for payments and TNZO.

10. Security model

• Consensus tolerates f Byzantine validators out of n = 3f + 1 by stake. Its safety does not depend on trusted hardware.
• Keys are rooted in hardware. There is nothing on disk to copy.
• Post-quantum cryptography protects validator channels, finality certificates and account signatures. Classical and post-quantum legs are combined so that an attacker must break both.
• TEEs are evidence about where a computation ran. They are never custody and never weight consensus.
• Economic security comes from bonds. Provable faults, such as double-signing a checkpoint, a missed SLA or a breach of an operator's own policy, burn or slash the bond.
• The RPC surface is closed by default.

11. Endpoints

curl -s https://rpc.tenzro.xyz \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_getFinalizedBlock","params":[]}'

12. Conclusion

Tenzro Network 1 is the full stack for the Machine Economy, designed from the ground up: post-quantum consensus, hardware-rooted keys, evidence-based trust, metered settlement, inference for any model and training for agents, all on one open network. To take part, run a node, start building or read the Network 1 documentation.