Tenzro Network MCP Server

Tenzro Network

Tenzro is the decentralized economic and compute substrate where AI agents and humans discover, transact, settle, and orchestrate intelligence across networks, VMs, and rails — EVM, SVM, Canton/DAML, cross-chain bridges, AP2 and x402 payments, decentralized AI inference, decentralized GPU training, TEE-backed confidential compute — under one identity (TDIP) and one settlement asset (TNZO).

What is Tenzro?

The economic substrate for AI agents and humans. Tenzro is the economic and compute infrastructure where AI agents live, transact, and collaborate — across every VM, every external chain, and every protocol. The thesis is straightforward: agents and humans need a single self-sovereign identity, a single threshold-secured wallet, a single settlement asset, and a single discovery and orchestration surface for decentralized AI and compute that work uniformly across every VM and every external chain they touch. Today they don't — agents hold one wallet per chain, identity is rebound at every protocol boundary, AI inference and GPU compute live behind opaque centralized APIs, and value can't cross from EVM to Canton without giving up custody. Tenzro fixes this at the protocol layer.

• Decentralized AI + compute orchestration: agents and humans discover and access AI inference (chat, vision, audio, forecasting, embeddings, segmentation, detection — 7 ONNX runtimes), GPU training capacity (Tenzro Train), and TEE-backed confidential compute (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA GPU CC) through a single protocol-level marketplace with per-token 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_rbpf 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 + training as protocol-level economic activity: providers earn TNZO for serving models (chat, vision, audio, forecasting, embeddings, segmentation, detection), 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 ships 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. Three 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 Decoupled DiLoCo–style protocol. 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 ships 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.
• 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. Where Render rents raw GPUs and Bittensor coordinates subnet intelligence, Tenzro unifies inference, training, agent settlement, identity, verification, and cross-chain reach under one tokenized substrate.

What Tenzro Does That No Other Network Does

Tenzro is the only protocol in 2026 that combines EVM + SVM + Canton/DAML in a single network. The closest analog (Fluent, mainnet 2026-04-24) ships EVM + SVM + Wasm but no DAML — and DAML is the execution environment the institutional RWA surface (regulated tokenized treasuries, bank deposit tokens, CIP-56 settlement) is converging on.

That makes Tenzro the only network that natively bridges 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) under 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. Phala, Oasis Sapphire/ROFL, and NEAR AI all run TEE compute 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 — full spec at docs/papers/tenzro-consensus.md.
• 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 (490+) + MCP (330+) + A2A (42) |
                    +--------------+----------------------+
                                   |
        +----------+---------------+---------------+----------+
        |          |               |               |          |
   +----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 — 26 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

# 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 --role validator --data-dir ./data

# Light client
./target/release/tenzro-node --role user --data-dir ./data

# Model provider
./target/release/tenzro-node --role model-provider --data-dir ./data

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 ships full revm integration 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 (real hardware attestation), 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 the Solana BPF runtime (solana_rbpf) so Solana programs run unmodified. 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.

• Distributed Mixture-of-Experts serving. MoE models (Qwen 3.5 122B-A10B / 397B-A17B, DeepSeek V3 / V4 Pro 1.6T-A49B / V4 Flash, GLM 5.1 / 5.2, Kimi K2 / K2.6, MiniMax M3, Gemma 4 26B-A4B) serve in two modes. Full-replica when one provider's hardware fits the model. Decentralized expert shards when it doesn't — providers declare which experts they hold via ProviderCapacity.moe_holdings, and the dispatch planner aggregates per-token top-k routing decisions into per-holder batches dispatched directly over the holder's iroh QUIC endpoint. The shard view is a derived view over the existing provider registry — MoE providers are the same network providers that serve dense models. Replication is governance-tunable (default ≥ 2 holders per expert, up to 8 for popular experts). Typed pipeline roles: Replica, Router, ExpertHolder, PrefillDecode, Prefill, Decode. RPCs: tenzro_moeShardMap, tenzro_moePlanDispatch, tenzro_moeReplicationPolicy, tenzro_moeCatalogShape.
• Multi-Token Prediction (MTP) — full path wired. Speculative decoding wired through the catalog → provider capacity → router → llama.cpp --spec-type draft-mtp path. Wired for DeepSeek V3 (native, ~80% accept rate, ~1.8× decode), DeepSeek V4 Pro / Flash, GLM 5.2, Gemma 4 (all sizes), Qwen 3.5 (0.8B/2B/4B/9B/27B/35B-A3B/122B-A10B/397B-A17B), and Qwen 3.6 27B + 35B-A3B. Providers advertise drafter co-load via ProviderCapacity.mtp_enabled; the inference router filters MTP-eligible requests to MTP-capable providers when draft_n is set.
• Decentralized training — Tenzro Train (Decoupled DiLoCo). Rust protocol layer (tenzro-training) owns the syncer state machine, four aggregation rules (Mean / TrimmedMean / CoordinateMedian / Krum), Nesterov outer optimizer, fragment commitment, training receipts, and on-chain run-root commitments. Python reference trainer wraps PyTorch FSDP2 + Hivemind + safetensors for per-modality inner loops (transformers, native PyTorch, gluonts, timm). k-of-N witness committee with idempotent finalization and no-endorsement certificates handles multi-syncer coordination across regions. Confidential tier uses HPKE RFC 9180 base-mode wrapping of per-shard data keys to enclave-resident trainers (data unsealed only inside the trainer's TEE). Three trust tiers: Open (Mean only), Verified, Confidential.
• Cortex. Recurrent-depth-Transformer reasoning workers exposed as a separate compute lane — HTTP sidecar architecture, signed receipts, attestation suite, gossip-based worker discovery, depth-priced billing.
• Confidential inference. Model providers can wrap inference inside an Intel TDX / AMD SEV-SNP / AWS Nitro / NVIDIA GPU CC enclave; the result hash is signed with an enclave-bound key and the attestation chain verifies through TEE_VERIFY on-chain.

Multi-modal inference

The catalog spans seven ONNX runtimes plus the llama.cpp language path, all dispatched by the modality-aware InferenceRouter::route() against typed InferencePayload (Chat / Forecast / VisionEmbed / VisionSimilarity / TextEmbed / Segment / Detect / Transcribe / VideoEmbed). License tiers — Permissive (Apache/MIT/BSD), Attribution (CC-BY-4.0), CommercialCustom (DINOv3, SAM, Gemma — require --accept-license), NonCommercial (refuse without --accept-non-commercial) — gate registration. Forecast (TimesFM 2.5), Vision embedding (CLIP, SigLIP2, DINOv3, DINOv2), Text embedding (Qwen3-Embedding, EmbeddingGemma Matryoshka, BGE-M3, Snowflake Arctic), Segmentation (SAM 3 / 3.1, SAM 2, EdgeSAM, MobileSAM), Detection (RF-DETR, D-FINE), Audio ASR (Moonshine v2, Distil-Whisper, Whisper v3 turbo, Parakeet-TDT, Canary-1B-Flash), Video (vision-fallback encoder over uniformly-sampled frames). Each modality is exposed through JSON-RPC, MCP, A2A, and a CLI subcommand.

Identity (TDIP) — four classes

• did:tenzro:human:{uuid} — KYC tier, controlled machines, controller of any number of delegated agents.
• did:tenzro:machine:{controller}:{uuid} — delegated agent acting on behalf of a human, institution, or upstream machine. Carries a delegation scope (per-tx cap, daily cap, allowed operations / chains / payment protocols / counterparties, time bound).
• did:tenzro:machine:{uuid} — autonomous agent. Same wallet and A2A surface, no controller. Marks is_seed_agent for protocol-funded bootstrap agents.
• did:tenzro:institution:{lei}:{uuid} — legal entity anchored to its 20-character GLEIF Legal Entity Identifier (ISO 17442) with ISO 7064 Mod 97-10 check-digit validation at registration. Optional vLEI ACDC credential id binding, ISO 3166-1 alpha-2 country code, KYB tier. One legal entity can hold multiple institution identities (one per desk / fund / subsidiary) without re-issuing LEIs.

W3C DID Documents. W3C Verifiable Credentials with recursive trust-chain verification (cycle detection, depth bound, anchored to configured trust roots). KYC/KYB tier upgrades via credential. Cascading revocation. Universal Resolver at /1.0/identifiers/{did} (DIF spec) for any standards-compliant client. KERI Key Event Log for long-lived autonomous machine identities (inception, rotation, interaction events with pre-rotation commitments; SAID prefix S for SHA-256). Sign-In With Tenzro (SIWT) — EIP-4361-shaped message for off-chain service authentication.

Payments

Crypto rails — settle on-chain in TNZO or stablecoins:

• AP2 (Agent Payments Protocol): Google/FIDO protocol for verifiable agent payments using intent/cart/payment VDCs; mandate-pair validation via tenzro_validateMandatePair
• MPP (Machine Payments Protocol): Session-based streaming payments, co-authored by Stripe and Tempo
• x402 (Coinbase): Stateless HTTP 402 payments with EIP-3009 authorization
• Tempo: Direct stablecoin settlement with EIP-155 transaction signing
• HTTP middleware for automatic payment challenge/verification

Card rails — Visa/Mastercard settle fiat; Tenzro provides identity + delegation + audit:

• Visa TAP (Trusted Agent Protocol): the agent presents a Tenzro-issued mandate envelope (DID + signed delegation scope + AP2 mandate validation); Visa authorizes and settles the card transaction; Tenzro records the on-chain audit receipt
• Mastercard Agent Pay: same identity/delegation/audit substrate; Mastercard settles the card transaction

This means a single agent identity can compose a card-rail TAP payment, an x402 USDC micropayment, and a Canton DvP leg in one task with one delegation envelope and one audit trail — across rails that otherwise cannot interoperate.

Security

• Real TEE integration: Intel TDX (/dev/tdx-guest), AMD SEV-SNP (/dev/sev-guest), AWS Nitro (/dev/nsm), NVIDIA GPU CC (NRAS API)
• X.509 certificate chain verification with pinned vendor root CAs
• AES-256-GCM enclave encryption with HKDF key derivation
• Plonky3 STARK proofs over KoalaBear (no trusted setup, post-quantum sound), with on-chain ZkCommitmentRegistry for O(1) EVM verification
• FROST-Ed25519 (RFC 9591) 2-of-3 threshold wallets with Argon2id key derivation, paired with mandatory ML-DSA-65 post-quantum signatures
• VRF (RFC 9381 ECVRF-EDWARDS25519-SHA512-TAI) for provably-fair randomness — precompile 0x1007, NFT mintRandom (0x52517e21)

Cross-Chain Bridge (15 production adapters)

• LayerZero V2: EndpointV2 messaging, OFT with shared decimals
• Stargate V2 Hydra: native USDC / USDT / WETH OFT bridging (separate adapter; LayerZero V2 underneath)
• Chainlink CCIP: Router-based cross-chain messaging with token pools
• Chainlink CCT: Cross-Chain Token v1.6+ self-serve pool registry (LockRelease + BurnMint)
• Wormhole: 19-guardian VAA attestation, 30+ chains incl. Solana/Aptos/Sui
• Wormhole NTT: Native Token Transfers with NttManager registry + multi-transceiver chain catalog (Wormhole / Axelar / LayerZero / custom)
• deBridge DLN: Intent-based cross-chain swaps (official MCP proxy)
• LI.FI: 66-chain aggregation with route optimization
• Hyperlane V3: messaging with sovereign Tenzro-validator-set ISM (list_chains, quote_dispatch, dispatch)
• Axelar GMP: Cosmos / Move / Stellar / XRPL reach
• Babylon: Bitcoin staking finality-providers + EOTS delegations
• IBC-Eureka: Tendermint light client compressed into SP1 plonk proofs for every Cosmos SDK chain. On-EVM IBC_VERIFY precompile at 0x1020 is an O(1) lookup against the off-EVM commitment registry.
• BitVM2 / Clementine: trust-minimised Bitcoin two-way peg with optimistic challenge protocol. Peg-in / peg-out lifecycle tracked on-chain; default 7-day settlement window.
• Hyperbridge ISMP: HTTP-shaped POST/GET messaging into Polkadot. Mint-control + per-asset rolling-window liquidity ceilings enforced at the message-ingest path.
• NEAR Chain Signatures: NEAR MPC produces secp256k1 / Ed25519 signatures for Bitcoin, Ethereum, Solana, TON, Stellar, Sui, Aptos, Dogecoin from a Tenzro account.
• Canton: Enterprise DAML interoperability

A unified BridgeRouter consults live fee quoting and returns a ranked set of routes by cost, speed, or reliability. Every adapter is fail-closed on inbound message verification (Guardian quorum for Wormhole, threshold validator set for Hyperlane + Axelar, ISMP proof for Hyperbridge, BitVM2 challenge protocol for Clementine). Per-adapter nonce trackers persist so replays are dropped across restarts. A global supply accounting registry at precompile 0x1021 is the single integrity log for Tenzro-issued tokens that move across rails — enforces monotone per-(asset, rail) sequence (replay guard), Σ mints − Σ burns ≤ max_supply, and no underflow on burn.

Bridge Fee in TNZO + Chainlink-backed Fee Oracle

• Single-token UX: users pay one TNZO-denominated fee on the source chain; the destination-native fee is fronted by a per-adapter sponsorship pool.
• Two oracle backings: GovernanceSetFeeOracle (manual rate table, admin-token-gated via tenzro_setBridgeFeeRate) and ChainlinkFeedFeeOracle (live eth_call against AggregatorV3Interface.latestRoundData() with 30s in-memory cache + staleness + invalid-answer rejection).
• Per-adapter sponsorship pools: 8 deterministic vault addresses (SHA-256 over "tenzro/bridge/sponsorship-vault" || adapter, first 20 bytes), enumerable via tenzro_listBridgeSponsorshipPools.
• ERC-7683 envelope unification: TenzroOrderData.bridge_fee_hint lets a single user-signed order be filled by any of the 6 bridges — solver picks the adapter, the TNZO ceiling bounds the destination-native commitment.
• Operator-gated upstream cost: the Ethereum mainnet RPC quota for Chainlink reads is operator-paid; methods are gated by API key with chainlink scope (same model as Canton). Per-tenant Compute Unit attribution in CF_BRIDGE_ANALYTICS. GCRA rate limiter (10 req/sec sustained, burst 100) with -32005 retry envelope.

Tokenization & Compliance

• ERC-7943 (uRWA): real-world-asset compliance surface — token kill-switch (tenzro_urwaTriggerKillSwitch), freeze-tokens (tenzro_urwaSetFrozenTokens), forced-transfer (admin-token-gated).
• IVMS101 v1.1.0: FATF Travel Rule canonical envelope binding for KYC payloads on cross-border transfers.
• Secure-Mint: per-token 1:1 reserve-attestation invariant for tokenized RWAs.
• TEE-attested timestamps: saga step deadlines and obligation expiries carry a TEE-attested wall_ms + monotonic_ns + tee_vendor envelope with 30s drift tolerance.

Agent Interoperability

• ERC-8004: Trustless Agents Registry on Ethereum — mirror Tenzro machine DIDs to the registerAgent/getAgent/submitFeedback/validationRequest/validationResponse interface for cross-ecosystem agent reputation. CLI exposes both tenzro erc8004 and the canonical EIP-8004 short-name alias tenzro 8004.
• AP2: Agent Payments Protocol with intent/cart/payment VDC mandates, session lifecycle, and mandate-pair validation
• AAP (Agent Access Protocol): OAuth 2.1 + DPoP + RAR layering for agent-issued bearer tokens. The CLI exposes both tenzro auth and the alias tenzro aap — both names hit the same tenzro_*Token* and wallet-link RPCs.

Multi-Party Workflows (VM-agnostic; Canton mirror optional)

The workflow runtime is its own state machine. It runs alongside (not inside) the VMs and carries its own typed lifecycle, per-step execute / verify / compensate handlers, on-chain receipts under privileged-VM transaction selectors, fee routes, kill switch, and privacy domains. Canton mirroring is an optional projection — a workflow can declare canton_mirror: Some(...) and the workflow dispatcher will write a Tenzro.Workflow.Receipt row through the co-located Canton participant for every step; a workflow with canton_mirror: None runs without Canton interaction. EVM contracts subscribe to workflow events through the standard event surface. SVM programs observe receipts through the unified token registry's event log.

• Lifecycle: typed state machine (Draft → Active → AwaitingSignatures → Executing → Completed, terminal Cancelled / Disputed / Failed / Suspended) with privileged-VM selectors 0x01000040–0x0100004B for every state change.
• Receipts: every transition produces a WorkflowReceipt linked into a per-workflow hash chain, persisted under wf_receipt:<id> and (optionally) mirrored to a Tenzro.Workflow.Receipt Daml template through the co-located Canton participant.
• Privacy domains: named ACLs of TDIP DIDs gate AES-256-GCM-sealed payloads with auditor read-through and governance-driven freeze.
• Fee routes: basis-point recipient tables with tenzro_computeFeeRoutePayouts for read-only previews; actual settlement runs through the consensus-mediated escrow primitive.
• Kill switch: KillSwitchSuspend / KillSwitchCancel selectors give the initiator a defined emergency-stop path so an autonomous agent can never be trapped in a non-responsive multi-party flow it originated.
• Surfaces: read-only access via JSON-RPC (tenzro_*), MCP (port 3001), and A2A (workflow skill on the Tenzro Agent Card). Operational-metrics snapshot at /metrics with bundled Grafana dashboard (UID tenzro-workflow).
• Reference templates: 5 live under crates/tenzro-workflow/reference_workflows/ (autonomous procurement, autonomous treasury, DvP settlement, environmental MRV, supply-chain DPP), each paired with a **_daml_map.json` describing the optional Canton DAML projection.

Compliance & Disclosure (EU AI Act Article 50)

• §50(1) chatbot disclosure: every CLI / MCP / A2A AI text response is prefixed with [AI]. Single source of truth in tenzro_node::eu_ai_disclosure.
• §50(2) synthetic-content marker: every inference output carries a C2PA-style ProvenanceManifest keyed by SHA-256 content hash. Validators sign manifests with their Ed25519 block-signing key. RPC tenzro_getProvenance and CLI tenzro provenance get <content_hash> resolve the cached manifest.
• §50(4) deepfake assertion tag: outputs imitating real subjects use the deepfake assertion in place of ai-generated.
• Approval flow: out-of-scope agent operations are parked for controller review. Inspect via tenzro approval list/get and decide via tenzro approval decide.
• Channel disputes: durable lifecycle records readable via tenzro dispute status and tenzro dispute list-by-channel.
• Provider reputation: tenzro reputation get <provider> reads the durable score (0–1000, +1 success / −5 failure) used by the inference router.

Ecosystem

Documentation truncated — see the full README on GitHub.