Tenzro Network

Tenzro is the open, distributed execution layer for AI. Inference, agents, and workflows run across a network of independent nodes instead of one company's servers. Any machine can serve a model, rent out spare compute, and hold data — one stake covers every role, and TNZO settles all of it: consumers pay from their balance, providers earn into theirs. Underneath sit the substrate layers that make execution open — multi-VM settlement (EVM, SVM, Canton/DAML), cross-chain reach, one identity (TDIP), and one settlement asset (TNZO).

What is Tenzro?

The open, distributed execution layer for AI. Tenzro is where inference happens, where agents act, and where workflows run — across a network of independent nodes rather than one company's servers. The thesis is straightforward: AI needs somewhere to run that no single provider controls. That means nodes anyone can join, a way to pay for what you use and earn for what you serve, and proofs anyone can check. Today inference and compute live behind opaque centralized APIs, identity is rebound at every protocol boundary, and value can't cross from EVM to Canton without giving up custody. Tenzro fixes this at the protocol layer.

• Multi-role nodes: one node, one stake, many roles. A node can serve AI models, rent out spare compute, and hold data at the same time — a single stake covers every role it takes on. Compute rental is availability-proof-gated and billed per epoch; storage is proof-of-retrievability-gated and billed per byte-epoch. In every case the consumer pays from their TNZO balance and the provider earns into theirs.
• Decentralized AI + compute orchestration: agents and humans discover and access AI inference (chat, vision, audio, forecasting, embeddings, segmentation, detection), rentable compute capacity, and TEE-backed confidential compute (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA GPU CC) through a single protocol-level marketplace with per-use billing, reputation scoring, and on-chain verifiability. Providers are sovereign — anyone can run a model, expose an endpoint, or contribute compute, and earn TNZO directly. The inference router (price / latency / reputation / weighted strategies) and the agent-spawning + swarm-orchestration primitives let agents compose multi-model, multi-provider workflows without trusting any one party.
• Universal identity (TDIP): one DID for humans, delegated agents, and autonomous agents that works on EVM (via ERC-8004 mirror), SVM, Canton (CIP-26 user binding), AP2 mandates, x402 micropayments, and OAuth/DPoP — same identity, same delegation scope, same revocation surface.
• Universal wallet (FROST-Ed25519 + ML-DSA-65 hybrid PQ): threshold-secured, hardware-attestable, and one balance shared across three VM views — wTNZO ERC-20 on EVM, SPL adapter on SVM, CIP-56 holding on Canton. No bridge risk, no liquidity fragmentation. Pointer-model native asset.
• Universal settlement (TNZO): bridge fees, inference fees, escrow, micropayment channels, training-run grants, and cross-chain destination-native fees (via the Chainlink-backed bridge fee oracle) all denominated and accounted in TNZO.
• Cross-chain reach as a wire primitive: LayerZero V2, Chainlink CCIP, Chainlink CCT, Wormhole + NTT, deBridge DLN, LI.FI, Hyperlane V3, Axelar GMP, Babylon Bitcoin staking, and Canton — all behind one ERC-7683 envelope with BridgeFeeHint. Users sign once, solvers pick the bridge.
• Multi-VM execution: EVM (revm + 9 standard precompiles + 7 BLS12-381 EIP-2537 + 13 Tenzro precompiles) + SVM (solana-svm with SPL Token Program dispatch) + Canton 3.5+ DAML — every contract, every instruction, every command runs against the same identity, same wallet, same TNZO balance.
• AI inference, generation, and training as protocol-level economic activity: providers earn TNZO for serving models (chat, vision, audio, forecasting, embeddings, segmentation, detection), rendering diffusion image and video jobs (Tenzro Media Gen), running TEE enclaves, and contributing GPU compute to verifiable training runs (Tenzro Train). Inference results, settlements, and identity claims are verifiable on-chain via Plonky3 STARKs over the KoalaBear field (transparent setup, post-quantum-conjectured soundness) or attested by hardware enclaves (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA GPU CC) — both anchored via ZK_VERIFY and TEE_VERIFY precompiles.
• Humans as peer identity class: HITL escalation, guardian-quorum recovery, AP2 cart/intent/payment mandates, and delegation scopes are wire primitives, not adapter-layer features.

Tenzro Network is also the reference implementation of the Open Agent Network (OAN) — the standards family (TNIP-001..022) for a hybrid human + agent coexisting network. OAN provides the governance framework; Tenzro Network is the working implementation. The wire stays open for other implementations.

Compute as Currency

Tenzro turns AI compute into a unit of economic exchange — denominated, settled, and verified in TNZO. Four surfaces share the same identity, payment, and settlement substrate:

• Tokenized AI inference. Anyone can run AI models (chat, vision, audio, forecasting, embeddings, segmentation, detection) and offer them on the marketplace. Users and agents pay per token (or per inference); providers earn TNZO directly. Confidential variants run inside TEE enclaves (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA GPU CC). Micropayment channels make high-frequency, low-value billing efficient.
• Tokenized AI training (Tenzro Train). Decentralized verifiable training using a data-parallel protocol with decoupled outer synchronization. GPU providers contribute compute and earn TNZO; sponsors fund runs from on-chain escrow. Every accepted outer gradient produces a signed receipt, and every run finalizes a run-root commitment on-chain. Phase 1 covers timeseries first, with simple mean aggregation, stake bonding, and the Open trust tier; Byzantine-robust aggregation, multi-region scale, and TEE-resident data are roadmap.
• Tokenized media generation (Tenzro Media Gen). Diffusion image and video jobs are posted with a price ceiling, claimed by a worker, rendered, and settled against a signed receipt over what was produced. The work unit is the pixel-step (width × height × steps × frames). Models whose transformer is split into a high-noise and a low-noise expert render across two accelerators that could not each hold the whole model: exactly one intermediate latent crosses between the halves, and the payment divides by the share of the denoising schedule each half signed for.
• Agentic finance. Autonomous agents discover providers, negotiate, pay, and settle in TNZO using the same TDIP identity, FROST-Ed25519 threshold wallet, and delegation scope. AP2 mandates, x402 micropayments, ERC-8004 trustless-agent registries (mirrored across EVM, SVM, and DAML from a single TDIP write), and ERC-4337 v0.8 smart accounts all run inside Tenzro consensus.

Verifiability is not optional. Inference results, settlements, and identity claims can be proven via Plonky3 STARKs over the KoalaBear field (transparent setup, post-quantum-conjectured soundness) or attested by hardware enclaves — both anchored on-chain via the ZK_VERIFY and TEE_VERIFY precompiles. Tenzro unifies inference, compute rental, storage, training, agent settlement, identity, verification, and cross-chain reach under one open execution layer — not raw GPU rental and not subnet coordination, but the full surface where AI runs.

The Combination

Individually, the pieces exist elsewhere. What Tenzro composes into one network is the combination: verifiable AI inference and training, confidential compute, multi-modal serving, and agent settlement, all under one identity, one settlement asset, and one consensus layer.

Tenzro combines EVM + SVM + Canton/DAML in a single network — and DAML is the execution environment the institutional RWA surface (regulated tokenized treasuries, bank deposit tokens, CIP-56 settlement) is converging on. That breadth is the substrate; the execution layer for AI is what rides on top of it.

On that substrate, retail-agent rails (AP2 mandates, x402 micropayments, ERC-8004 trustless agents, ERC-4337 v0.8 smart accounts) and institutional-RWA rails (Canton DAML, CIP-56 tokens, DvP settlement) share one identity (TDIP), one settlement asset (TNZO), and one consensus layer.

Two more architectural calls worth flagging:

• Confidential agent compute is a consensus primitive, not a sidecar. TEE-attested validators get a 1.5× multiplier on their reputation-weighted leader-selection draw; the TEE_VERIFY precompile verifies real Intel TDX, AMD SEV-SNP, AWS Nitro, and NVIDIA GPU CC quotes on-chain — attested execution is built into consensus, not bolted on as middleware over a non-TEE chain. Tenzro consensus is two-phase HotStuff-2 with reputation-weighted proposer election, no-endorsement certificates for tail-fork resistance, and Ed25519 + ML-DSA-65 hybrid post-quantum signatures on every safety-critical message.
• TNZO is a pointer-model native asset. One balance, three VM views (wTNZO ERC-20 on EVM, SPL adapter on SVM, CIP-56 holding on Canton) — no bridge risk, no liquidity fragmentation. Registered upstream via CAIP-2 (tenzro namespace), SLIP-44 (1414421071 / 0xd44e5a4f), and W3C DID (did:tenzro).

For the full architecture see docs/WHITEPAPER.md and docs/SPECIFICATION.md.

Architecture

                    +-------------------------------------+
                    |         User Interfaces             |
                    |      CLI / SDKs / MCP / A2A         |
                    +--------------+----------------------+
                                   | JSON-RPC + HTTP
                    +--------------v----------------------+
                    |           tenzro-node               |
                    |   RPC (855) + MCP (526) + A2A (41)  |
                    +--------------+----------------------+
                                   |
        +----------+---------------+---------------+----------+
        |          |               |               |          |
   +----v---+ +---v----+ +-------v--------+ +---v---+ +---v----+
   |Network | |Consensus| |  Multi-VM      | |Storage| | Model  |
   |(libp2p)| |HotStuff2| | EVM+SVM+DAML  | |RocksDB| |Registry|
   +--------+ +--------+ +----------------+ +-------+ +--------+
        |          |               |               |          |
   +----v----+----v----+----------v-----+---------v-+--------v---+
   |  Crypto  |  TEE   |   ZK Proofs   | Identity  | Payments   |
   | Ed25519  | TDX    |  Plonky3 STARK| TDIP/DID  | MPP/x402   |
   | Secp256k1| SEV-SNP|  KoalaBear/FRI| W3C VC    | Tempo      |
   | BLS12-381| Nitro  |  Poseidon2    | KYC Tiers | Stripe/CB  |
   | AES-GCM  | GPU CC |  No setup, PQ | Delegation| EIP-155    |
   +----------+--------+---------------+-----------+------------+

Workspace — 32 Crates

Quick Start

Install from Homebrew

brew tap tenzro/tap
brew install tenzro

Build from Source

# Requires Rust 1.85+
cargo build --release -p tenzro-node -p tenzro-cli

# Binaries at:
# ./target/release/tenzro-node
# ./target/release/tenzro

Join the Network

# Guided setup — join the public network (consume, provide, or validate),
# create a local or sovereign network, or join an existing private network
tenzro setup

# Join — provisions identity + FROST-Ed25519 threshold wallet + hardware profile
tenzro join --name "Your Name"

# Mint a DPoP-bound bearer JWT for authenticated RPC/MCP access
tenzro auth onboard-human --display-name "Your Name"

# Request testnet TNZO
tenzro faucet

# Check balance
tenzro wallet balance

# Send tokens
tenzro wallet send --to <address> --amount 10

# Interactive mode
tenzro interactive

Run a Node

# Validator node
./target/release/tenzro-node --roles validator --data-dir ./data

# Light client
./target/release/tenzro-node --roles light --data-dir ./data

# One node serving inference and holding storage under one stake
./target/release/tenzro-node --roles ai,storage --data-dir ./data

Run Your Own Network

# Bootstrap a self-contained network: validator keyset, schema-v1 genesis,
# service unit, and the exact join command for each peer
tenzro setup --path local --network-name lab

# Join an existing private network
tenzro setup --path private --genesis ./genesis.toml --bootstrap <multiaddr>

Become a Provider

Bring your GPU, cluster, or data center and earn from network demand. With a node running (tenzro-node --roles ai), one command handles everything:

tenzro join --provider

Hardware detection, wallet provisioning, faucet funding, the 1,000 TNZO compute bond the model-provider rung requires, provider registration, default pricing, and pulling + serving the largest catalog model that fits your machine are all automatic. Your capacity is advertised on the provider gossip topic and inference demand routes to you, settling in TNZO per call.

AI Inference

# List available models
tenzro model list

# Serve a model as a provider
tenzro model serve --model gemma3-270m

# Start an interactive chat session
tenzro chat

Protocol Servers

The node exposes 4 protocol servers, plus 6 ecosystem MCP servers:

Core Servers

Ecosystem MCP Servers

Authentication (Tiered)

• Public tools (no auth): get_node_status, list_models, get_balance, resolve_did, debridge_search_tokens, etc.
• Write tools (auth required): send_transaction, create_wallet, stake_tokens, register_identity, etc.
• Auth method: OAuth 2.1 + DPoP (RFC 9449) — bearer JWT minted via tenzro_onboardHuman / tenzro_onboardDelegatedAgent / tenzro_onboardAutonomousAgent. Each request carries Authorization: DPoP <jwt> plus a fresh DPoP: <proof> header (per-request JWS-compact, bound to the JWT's cnf.jkt thumbprint per RFC 7638). RAR scopes (RFC 9396) constrain the JWT to specific tools and amounts.
• API keys (operator-issued): tnz_... keys minted by the RPC operator via tenzro_createApiKey (admin-token-gated) and presented as X-Tenzro-Api-Key. Scopes gate methods that consult third-party paid resources: canton (Canton JSON Ledger API), chainlink (Ethereum mainnet RPC quota for Chainlink Data Feeds + bridge fee oracle + per-adapter sponsorship), evm / svm / inference / tee / bridge for operators who monetise those surfaces. Per-tenant counters in CF_CANTON_ANALYTICS + CF_BRIDGE_ANALYTICS. GCRA rate-limit on chainlink-scoped methods.
• Revocation: tenzro_revokeJwt (single token by jti) or tenzro_revokeDid (cascading through the act-chain).
• Config: TENZRO_MCP_AUTH=tiered (default) | false (dev) | full (all tools require auth)

Key Features

Multi-VM Execution — three VMs, one state machine

A chain that picks one VM forces every workload to fit that VM. Tenzro runs three and routes by transaction type. All three share the same state, the same gas token (TNZO), the same TDIP identity, and the same consensus.

• EVM — liquidity and composability. The Ethereum surface targets the broadest pool of existing contracts and tooling. Tenzro embeds revm with every standard precompile (ecRecover, SHA-256, RIPEMD-160, Identity, ModExp, EC_ADD, EC_MUL, EC_PAIRING, BLAKE2F) per the canonical EIPs, plus all seven BLS12-381 precompiles (EIP-2537) for native consensus-grade signature aggregation. Block-STM gives parallel transaction execution with MVCC concurrency control and automatic sequential fallback under contention. EIP-1559 dynamic fee market burns the base fee. Native primitives extend the EVM with protocol-aware precompiles: TEE_VERIFY (hardware attestation with vendor certificate-chain validation), ZK_VERIFY (O(1) commitment lookup against the on-chain Plonky3 registry), VRF_VERIFY (RFC 9381 ECVRF), IBC_VERIFY (IBC-Eureka light-client lookup), the Tenzro precompile slate (TNZO_BRIDGE, TOKEN_FACTORY, CROSS_VM_BRIDGE, STAKING, GOVERNANCE, NFT_FACTORY, MODEL_INFERENCE, SETTLEMENT, global supply accounting at 0x1021, module registry at 0x1022), ERC-4337 v0.8 account abstraction, EIP-7702 Type-4 delegation, Permit2 SignatureTransfer with witness binding, and ERC-7579 modular validator modules (social recovery / session keys / spending limits / WebAuthn passkey / TEE-bound).
• SVM — throughput and latency. The Solana surface targets workloads that need sub-second finality and high throughput — DEX routing, agent-to-agent micropayments, real-time settlement on a path. Tenzro embeds Anza's solana-svm TransactionBatchProcessor (behind the svm-full cargo feature) so Solana SBF programs run unmodified; without that feature the SPL Token adapter, the cross-VM native program, and PDA derivation still work while the SBF path returns VmError::SvmFullFeatureRequired. The SPL Token program maps onto the native unified token registry — a swap on SVM settles in the same balance space as a transfer on EVM. There is no bridging between the two VMs.
• Canton DAML — privacy and institutional settlement. Canton is where the institutional financial system already settles tokenized cash, money-market funds, bonds, equities, treasuries, and OTC derivatives. Tenzro speaks Canton 3.5+ JSON Ledger API v2 directly. CIP-56 Canton Coin holdings round-trip with TNZO; CIP-26 user management binds each tenant to its own party with CanActAs rights enforced server-side; DAR upload, party allocation, command submission, and active-contract queries are all available through the same node API surface as EVM and SVM calls. Canton's privacy model means the transaction body is visible only to its signatories; Tenzro provides the cross-VM orchestration and the public commitment.
• Cross-VM token model — Sei V2 pointer. TNZO has a single canonical native balance. The wTNZO ERC-20 pointer on the EVM side and the wTNZO SPL adapter on the SVM side share the same underlying balance — there is no bridge between them, no wrapped/unwrapped distinction, no liquidity fragmentation. Canton CIP-56 holdings round-trip through the Canton bridge adapter. From the application's perspective, a wallet has one TNZO balance regardless of which VM it last touched.
• What this composes into. An agent settling a DvP between a tokenized treasury (Canton) and a stablecoin payment (EVM) executes the whole thing as one workflow through one identity. An agent paying for a Solana DEX swap and posting a receipt on Tenzro consensus does it with one TNZO balance. Cross-VM coordination is a workflow primitive, not application code.

Decentralized AI infrastructure

The protocol layer treats AI compute as a coordinated resource, not a centralized service.

Tenzro does not ship models of its own. Every model named anywhere in this README — Qwen, DeepSeek, GLM, Kimi, Gemma, MiniMax, FLUX, Wan, LTX, SAM, CLIP, Whisper and the rest — is a third-party checkpoint the network supports, not a first-party or proprietary one. The serving path is model-agnostic: load_model takes a GGUF path, and llama.cpp derives the architecture from the file's own metadata, so the ModelArchitecture enum is informational (for display and filtering) rather than an allowlist. A model with no catalog entry serves on documented defaults.

What the curated catalog buys you is metadata and convenience, not permission. Every one of its entries was chosen for being ungated — downloadable with no HuggingFace login — so a fresh node can fetch and serve without the operator holding an account.

Per-model configuration is pluggable, not a single forced schema. Models genuinely differ in what they need, and a lowest-common-denominator config would either fail the demanding ones or burden the simple ones. So a catalog entry is a set of optional, defaulted slots and a model declares only what actually applies to it: a multimodal projector (mmproj) only if it has one, a paired drafter and MTP kind only if it supports speculative decoding, a MoeShape only if it is sparse, a sampling ServingProfile where the defaults are wrong for that family, a ReasoningPolicy where the model has a thinking mode. Where a model's own chat template is broken upstream, TemplateFix names a vendored replacement — the catalog declares which fix, the inference client supplies the file — rather than the runtime special-casing that model. Anything left unset falls back to a documented default, which is why an uncatalogued GGUF still serves. The same shape holds