Tenzro Solana MCP

Tenzro Network

Tenzro は、AI 向けのオープンな分散実行レイヤーです。 推論、エージェント、ワークフローは、1 社のサーバーではなく、独立したノードのネットワーク上で実行されます。どのマシンでもモデルを提供し、余剰の計算リソースを貸し出し、データを保持できます。1 つのステークですべての役割を担い、TNZO がそのすべてを決済します。利用者は残高から支払い、提供者は残高に報酬を受け取ります。その基盤には、実行をオープンにする基盤レイヤーがあります。マルチ VM 決済（EVM、SVM、Canton/DAML）、クロスチェーン接続、単一の ID（TDIP）、単一の決済資産（TNZO）です。

Tenzro とは？

AI 向けのオープンな分散実行レイヤーです。 Tenzro は、推論が行われ、エージェントが動作し、ワークフローが実行される場所です。1 社のサーバーではなく、独立したノードのネットワーク上で実行されます。基本的な考え方は明快です。AI には、単一のプロバイダーが支配しない実行場所が必要です。そのためには、誰もが参加できるノード、利用した分を支払い、提供した分だけ報酬を得る仕組み、そして誰もが検証できる証明が必要です。現在、推論と計算処理は不透明な中央集権型 API の背後にあり、プロトコルの境界を越えるたびに ID が再設定され、EVM から Canton へ資産を移すにはカストディを手放さなければなりません。Tenzro は、プロトコルレイヤーでこれらの課題を解決します。

• マルチロールノード：1つのノード、1つのステーク、多数の役割。ノードはAIモデルを提供し、余剰コンピューティングリソースを貸し出し、データを保存できます。担うすべての役割を単一のステークでカバーします。コンピューティングリソースのレンタルは可用性証明を条件とし、エポック単位で課金されます。ストレージはデータの保管証明を条件とし、バイト・エポック単位で課金されます。いずれの場合も、利用者はTNZO残高から支払い、提供者は自身のTNZO残高に報酬を受け取ります。
• 分散型AIとコンピューティングのオーケストレーション：エージェントと人間は、単一のプロトコルレベルのマーケットプレイスを通じて、AI推論（チャット、ビジョン、音声、予測、埋め込み、セグメンテーション、検出）、レンタル可能なコンピューティング容量、TEEを活用した機密コンピューティング（Intel TDX、AMD SEV-SNP、AWS Nitro、NVIDIA GPU CC）を検索して利用できます。利用ごとの課金、レピュテーションスコア、オンチェーンでの検証可能性を備えています。提供者は主権を持ち、誰でもモデルを実行し、エンドポイントを公開し、コンピューティングリソースを提供して、TNZOを直接獲得できます。推論ルーター（価格／レイテンシ／レピュテーション／重み付け戦略）と、エージェントの生成およびスウォームオーケストレーションのプリミティブにより、エージェントは特定の単一の当事者を信頼することなく、複数のモデルや提供者を組み合わせたワークフローを構成できます。
• ユニバーサルID（TDIP）：人間、委任されたエージェント、自律型エージェントが1つのDIDを共有し、EVM（ERC-8004ミラー経由）、SVM、Canton（CIP-26ユーザーバインディング）、AP2マンデート、x402マイクロペイメント、OAuth／DPoPで利用できます。同じID、同じ委任範囲、同じ失効機能を使用します。
• ユニバーサルウォレット（FROST-Ed25519 + ML-DSA-65ハイブリッドPQ）：しきい値署名で保護され、ハードウェアによるアテステーションに対応し、3つのVMビューで残高を共有します。EVM上のwTNZO ERC-20、SVM上のSPLアダプター、Canton上のCIP-56保有資産です。ブリッジのリスクも流動性の分断もありません。ポインターモデルのネイティブ資産です。
• ユニバーサル決済（TNZO）：ブリッジ手数料、推論手数料、エスクロー、マイクロペイメントチャネル、トレーニング実行の助成金、クロスチェーンにおける送金先チェーンネイティブの手数料（Chainlinkを基盤とするブリッジ手数料オラクル経由）はすべてTNZO建てで計上・決済されます。
• ワイヤープリミティブとしてのクロスチェーン接続：LayerZero V2、Chainlink CCIP、Chainlink CCT、Wormhole + NTT、deBridge DLN、LI.FI、Hyperlane V3、Axelar GMP、Babylon Bitcoinステーキング、Cantonを、すべてBridgeFeeHintを含む1つのERC-7683エンベロープの背後で利用できます。ユーザーは1回だけ署名し、ソルバーがブリッジを選択します。
• マルチVM実行：EVM（revm + 9個の標準プリコンパイル + 7個のBLS12-381 EIP-2537 + 13個のTenzroプリコンパイル）+ SVM（solana-svmとSPL Token Programディスパッチ）+ Canton 3.5+ DAMLに対応します。すべてのコントラクト、すべての命令、すべてのコマンドが、同じID、同じウォレット、同じTNZO残高を使用して実行されます。
• プロトコルレベルの経済活動としてのAI推論、生成、トレーニング：提供者は、モデルの提供（チャット、ビジョン、音声、予測、埋め込み、セグメンテーション、検出）、拡散モデルによる画像・動画ジョブのレンダリング（Tenzro Media Gen）、TEEエンクレーブの実行、検証可能なトレーニング実行（Tenzro Train）へのGPUコンピューティングリソースの提供に対して、TNZOを獲得します。推論結果、決済、IDクレームは、KoalaBearフィールド上のPlonky3 STARK（トラステッドセットアップ不要、耐量子性が推測される健全性）を介してオンチェーンで検証可能であり、ハードウェアエンクレーブ（Intel TDX、AMD SEV-SNP、AWS Nitro、NVIDIA GPU CC）によるアテステーションも可能です。どちらもZK_VERIFYおよびTEE_VERIFYプリコンパイルを介して固定されます。
• 人間をピアIDクラスとして扱う仕組み：HITLエスカレーション、ガーディアンクォーラムによるリカバリー、AP2のカート／インテント／支払いマンデート、委任範囲は、アダプターレイヤーの機能ではなくワイヤープリミティブです。

Tenzro Networkは、ハイブリッドな人間とエージェントの共存ネットワークのための標準規格群（TNIP-001..022）であるOpen Agent Network (OAN)のリファレンス実装でもあります。OANはガバナンスフレームワークを提供し、Tenzro Networkはその稼働する実装です。ワイヤーはオープンに保たれ、他の実装も利用できます。

コンピューティングを通貨として

Tenzroは、AIコンピューティングを経済的な交換単位へと変えます。TNZO建てで、決済され、検証されます。4つの領域が、同じアイデンティティ、支払い、決済の基盤を共有します。

• トークン化されたAI推論。 誰でもAIモデル（チャット、ビジョン、音声、予測、埋め込み、セグメンテーション、検出）を実行し、マーケットプレイスで提供できます。ユーザーとエージェントはトークン単位（または推論単位）で支払い、プロバイダーはTNZOを直接獲得します。機密性を備えたバリアントは、TEEエンクレーブ（Intel TDX、AMD SEV-SNP、AWS Nitro、NVIDIA GPU CC）内で実行されます。マイクロペイメントチャネルにより、高頻度かつ少額の課金を効率化します。
• トークン化されたAIトレーニング（Tenzro Train）。 外部同期を分離したデータ並列プロトコルを使い、分散型で検証可能なトレーニングを実現します。GPUプロバイダーはコンピューティングを提供してTNZOを獲得し、スポンサーはオンチェーンのエスクローから実行に資金を提供します。受け入れられた外部勾配ごとに署名付きレシートが生成され、実行ごとに実行ルートのコミットメントがオンチェーンで確定します。フェーズ1ではまず時系列データを対象とし、単純な平均集約、ステークのボンディング、Open信頼ティアを提供します。ビザンチン耐性のある集約、マルチリージョンへの拡張、TEE内に配置されたデータはロードマップに含まれます。
• トークン化されたメディア生成（Tenzro Media Gen）。 拡散モデルによる画像・動画生成ジョブは、価格上限を設定して投稿され、ワーカーが取得してレンダリングし、生成内容に対する署名付きレシートに基づいて決済されます。作業単位はピクセルステップ（width × height × steps × frames）です。トランスフォーマーが高ノイズと低ノイズのエキスパートに分割され、どちらのアクセラレーターにもモデル全体を保持できないモデルでは、2つのアクセラレーターにまたがってレンダリングします。中間潜在表現は分割部分間をちょうど1回だけ移動し、支払いは各部分が署名したノイズ除去スケジュールの割合に応じて分配されます。
• エージェント型金融。 自律エージェントは、同じTDIPアイデンティティ、FROST-Ed25519しきい値ウォレット、委任スコープを使ってプロバイダーを見つけ、交渉し、支払い、TNZOで決済します。AP2マンデート、x402マイクロペイメント、ERC-8004のトラストレスエージェントレジストリー（単一のTDIP書き込みをEVM、SVM、DAML間でミラーリング）、ERC-4337 v0.8スマートアカウントは、すべてTenzroのコンセンサス内で実行されます。

検証可能性は必須です。推論結果、決済、アイデンティティの主張は、KoalaBearフィールド上のPlonky3 STARK（透明なセットアップ、耐量子性が予想される健全性）によって証明するか、ハードウェアエンクレーブによって証明できます。どちらもZK_VERIFYおよびTEE_VERIFYプリコンパイルを通じてオンチェーンにアンカーされます。Tenzroは、推論、コンピューティングのレンタル、ストレージ、トレーニング、エージェント決済、アイデンティティ、検証、クロスチェーン接続を、1つのオープンな実行レイヤーに統合します。単なるGPUレンタルでも、サブネットの調整でもなく、AIが実行されるすべての領域を網羅します。

組み合わせ

個々の要素は、ほかの場所にも存在します。Tenzro が1つのネットワークに統合するのは、検証可能な AI 推論とトレーニング、機密コンピューティング、マルチモーダルサービング、エージェント決済の組み合わせです。すべてを1つのアイデンティティ、1つの決済資産、1つのコンセンサスレイヤーのもとに集約します。

Tenzro は、EVM + SVM + Canton/DAML を1つのネットワークに統合します。DAML は、機関投資家向け RWA の領域（規制対象のトークン化国債、銀行預金トークン、CIP-56 決済）が収束しつつある実行環境です。この幅広さが基盤となり、その上で AI の実行レイヤーが稼働します。

この基盤の上では、リテールエージェント向けレール（AP2 マンデート、x402 マイクロペイメント、ERC-8004 トラストレスエージェント、ERC-4337 v0.8 スマートアカウント）と、機関投資家向け RWA レール（Canton DAML、CIP-56 トークン、DvP 決済）が、1つのアイデンティティ（TDIP）、1つの決済資産（TNZO）、1つのコンセンサスレイヤーを共有します。

注目すべきアーキテクチャ上の決定事項が、さらに2つあります。

• 機密性を保つエージェントのコンピューティングは、付加的な機能ではなくコンセンサスのプリミティブです。 TEE によるアテステーションを受けたバリデーターは、レピュテーション加重リーダー選出の抽選で1.5倍の倍率を得ます。TEE_VERIFY プリコンパイルは、実際の Intel TDX、AMD SEV-SNP、AWS Nitro、NVIDIA GPU CC のクオートをオンチェーンで検証します。アテステーション付き実行は、TEE を使わないチェーンにミドルウェアとして後付けされるのではなく、コンセンサスに組み込まれています。Tenzro のコンセンサスは、レピュテーション加重の提案者選出、末端フォーク耐性のための非支持証明書、安全性が重要なすべてのメッセージに対する Ed25519 + ML-DSA-65 ハイブリッド耐量子署名を備えた、2フェーズの HotStuff-2 です。
• TNZO はポインターモデルのネイティブ資産です。 1つの残高に対し、3つの VM ビュー（EVM 上の wTNZO ERC-20、SVM 上の SPL アダプター、Canton 上の CIP-56 保有）を提供します。ブリッジのリスクも流動性の分断もありません。CAIP-2（tenzro 名前空間）、SLIP-44（1414421071 / 0xd44e5a4f）、W3C DID（did:tenzro）を通じて、上流に登録されています。

アーキテクチャの全容については、docs/WHITEPAPER.md と docs/SPECIFICATION.md をご覧ください。

アーキテクチャ

                    +-------------------------------------+
                    |         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    |
   +----------+--------+---------------+-----------+------------+

ワークスペース — 32 クレート

Crate	説明
tenzro-types	コア型、定数、プリミティブ（内部依存関係なし）
tenzro-crypto	Ed25519、Secp256k1、AES-256-GCM、X25519、BLS12-381、FROST-Ed25519 閾値署名（RFC 9591）、VRF（RFC 9381 ECVRF-EDWARDS25519-SHA512-TAI）
tenzro-tee	TEE 抽象化：Intel TDX、AMD SEV-SNP、AWS Nitro、NVIDIA GPU CC、Intel Tiber Trust Authority（X.509 証明書チェーン検証付き）
tenzro-zk	KoalaBear フィールド上の Plonky3 STARK（Poseidon2 + FRI）、事前構築済みの 4 つの AIR（推論／決済／ID／pq-qc。最後のものは、ML-DSA-65 署名が BLS のように集約できないため、クォーラム証明書に簡潔な耐量子要素を付与します）、信頼できるセットアップ不要、耐量子サウンドネス
tenzro-network	libp2p P2P ネットワーキング（コントロールプレーン）：gossipsub、Kademlia DHT、ピア管理、レート制限、Identify + AutoNAT v2 + Circuit-Relay v2 + DCUtR によるパーミッションレスな NAT トラバーサル
tenzro-iroh	iroh データプレーン（コンテンツアドレス方式のトランスポート）：QUIC + iroh-blobs 上の IrohBackedResolver、DA バックエンド、グラデーションストア、シールドシャードストア、tenzro/a2a ALPN 上の A2A-over-iroh。tenzro://{blob,gradient,shard,manifest,memory}/... を解決します。TDIP にアンカーされた Pkarr ディスカバリー（EndpointId は TDIP キーとバイト単位で同一）
tenzro-storage	カラムファミリー、Merkle Patricia Trie、スナップショット、fsync による耐久性を備えた RocksDB
tenzro-wallet	FROST-Ed25519（RFC 9591）2-of-3 閾値ウォレット + ML-DSA-65 ハイブリッド耐量子要素、Argon2id キーストア、トランザクションビルダー、ノンス管理、鍵のゼロ化
tenzro-keystore-unlock	再起動後もウォレットのキーストアパスワードを再現する、プラットフォーム非依存の KeystoreUnlocker トレイト（StaticUnlocker、EnvUnlocker）。プラットフォーム依存関係がないため、OS クレートを取り込まずに wallet/node の公開 API に配置できます
tenzro-device-key	ハードウェアで保護された抽出不可能な P-256 デバイス鍵（macOS/iOS Secure Enclave、Touch ID / Face ID による認証）：生体認証の事前ハッシュ署名と、永続的なキーストアパスワードの導出に使われる安定したシークレットのラップ／アンラップ
tenzro-auth	認証エンジン：AAP（Agent Authentication Protocol）、DPoP、RAR（Rich Authorization Requests）、WebAuthn アテステーション検証。プラットフォームアカウントではなく、ピン留めされたベンダールートと照合して、鍵を保持するハードウェアについてデバイスが実際に証明した内容を検証します
tenzro-consensus	HotStuff-2 BFT：3 フェーズの PREPARE → COMMIT → DECIDE、バリデーターごとに 10％の上限を設けたステーク加重クォーラム（コンセンサス投票はステークを保有するバリデーターに限定。サービスロールはサービス証明報酬を獲得）、TEE 加重リーダー選出（1.5×）、二重署名の検出 + スラッシング、提案ではトランザクション本体ではなく証明書ハッシュを順序付けるバッチ可用性証明書、クォーラムで制御される ZK コミットメントアテステーション（ZK_VERIFY コミットメントは、独立した再検証に対する 2f+1 ステーク加重 BLS 証明書がある場合にのみ受理されます）
tenzro-vm	マルチ VM：EVM（revm）+ SVM（Anza solana-svm TransactionBatchProcessor、svm-full 機能の背後）+ DAML、Block-STM 並列実行、EIP-1559、ERC-4337 AA、ERC-7579 モジュラーバリデーター、EIP-7702 Type-4 委任レジストリ、Permit2 SignatureTransfer + witness（ERC-7683 対応のガスレスフロー）、Secure-Mint プリコンパイル（トークン化資産の 1:1 準備金アテステーション不変条件）、標準 EVM + EIP-2537 BLS12-381 + Tenzro プリコンパイル（0x1007 の TEE_VERIFY、ZK_VERIFY、VRF_VERIFY）
tenzro-token	TNZO トークンエコノミクス：トレジャリー、ステーキング、ガバナンス、エポック報酬、リキッドステーキング（stTNZO）
tenzro-identity	TDIP：人間／機械の統合 ID、W3C DID ドキュメント、検証可能なクレデンシャル、委任スコープ、GDPR 第 17 条の消去権（tenzro_forgetIdentity）
tenzro-payments	エージェント決済プロトコル。暗号資産レール（オンチェーンで決済）： AP2 v0.2（Google/FIDO）の委任署名 + 検証 + ペア検証、MPP（Stripe + Tempo）セッション、tenzro-hybrid、exact-eip3009、permit2、erc7710 スキームに対応する x402 v1（Coinbase）の HTTP 402 とリソース市場（有料リソースの登録／検出／登録解除、オファー検証、冪等な決済 ID）、TDIP cap-resolver + ERC-8004 ReputationRegistry クロス書き込みを備えた Stripe SPT（SharedPaymentToken）の発行 + 検証、Tempo（EIP-155 署名）、ERC-8004（2026 年 1 月改訂版）Trustless Agents Registry（Identity / Reputation / Validation、22 のサーフェス）。カードレール（Tenzro が ID + 委任 + 監査を提供し、カードネットワークが法定通貨を決済）： Visa TAP（Trusted Agent Protocol）、Mastercard Agent Pay。HTTP 402 ミドルウェア、RFC 9421 HTTP メッセージ署名。
tenzro-agent	AI エージェント基盤：A2A プロトコル、MCP ブリッジ、ケイパビリティアテステーション、永続的な永続化
tenzro-agent-kit	高水準エージェント SDK：スキル、ツール、決済プロトコルからエージェントを構成します
tenzro-model	モデルレジストリ、モダリティを考慮した推論ルーティング（価格／レイテンシー／レピュテーション）、コンテンツアドレス方式のピア優先モデル配布（BLAKE3 でハッシュ化した重み、tenzro://blob/<hash> URI、HfArtifactDownloader が iroh blobs 経由でピアから取得し、失敗時は HuggingFace にフォールバック。ModelHashRegistry は最初の記録者を優先し、読み込み前に検証します）。すでにディスク上にある数 GB のアーティファクトは参照として公開されるため（publish_path / ImportMode::TryReference）、配信モデルが blob ストアに重複して保存されることはありません。永続カタログ。llama.cpp によるローカル推論は、すべての ggml バックエンド（CUDA、ROCm、Metal、Vulkan、SYCL、OpenCL、WebGPU、MUSA、CANN、OpenVINO、zDNN、BLAS）に対応します（ビルドごとに 1 つ、それ以外は CPU）。マルチモーダル ONNX ランタイム：予測（TimesFM 2.5）、ビジョン（CLIP、SigLIP2、DINOv3、DINOv2）、テキスト埋め込み（Qwen3-Embedding、EmbeddingGemma、BGE-M3、Snowflake Arctic）、セグメンテーション（SAM 3 / 3.1、SAM 2、EdgeSAM、MobileSAM）、検出（RF-DETR、D-FINE）、音声 ASR（Moonshine v2、Distil-Whisper、Whisper-v3-turbo、Parakeet-TDT、Canary-1B-Flash）、動画（エンコーダーの骨組み）。ライセンス区分による制御：Permissive / Attribution / CommercialCustom / NonCommercial。
tenzro-cortex	再帰的深度推論ワーカー（RDT/MoE）：HTTP サイドカーアーキテクチャ、署名付きレシート、アテステーションスイート、ゴシップベースのワーカー検出、深度に応じた課金
tenzro-training	Tenzro Train プロトコルレイヤー（外側の同期を分離したデータ並列処理）：集約ルール（Mean、LoraAlternating、TrimmedMean、CoordinateMedian、Krum）、適応学習率を備えた Nesterov 外側オプティマイザー、ブロック単位の Int8/Int4 勾配量子化、2 ビットコーデックと、ドロップされたデータ量に対するローカルな誤差フィードバック累積器を用いたチャンク化 top-k スパース化、ストリーミングシャード同期、パイプライン学習グループ、同期器ステートマシン、オンチェーンの実行ルートコミットメント。integrations/trainer/ にある Python リファレンストレーナーと連携します。
tenzro-media-gen	Tenzro Media Gen プロトコルレイヤー：拡散ジョブキュー、ワーカーレジストリ、ピクセルステップ課金、分割エキスパートのクレームと潜在表現の引き渡し、比例決済分配、3 つの署名付きコミットメント（ジョブ ID／引き渡し／レシート）、コンテンツアドレス方式の出力ストア。integrations/media_gen/ にある Python リファレンスワーカーと連携します。
tenzro-settlement	エスクロー、マイクロペイメントチャネル、バッチ決済、紛争解決、ストリーミング型レンタルエスクロー：時間ベースの容量レンタルで、借り手のデポジット + 署名付き可用性証明に基づくエポックごとのストリーミング解放を行います。プロバイダーのステークはアクティブなレンタル全体の 1 エポック分のエクスポージャーを担保し、未履行時にはステークから補填します
tenzro-storage-provider	iroh コンテンツアドレス方式トランスポートによる分散ストレージ：プロバイダーデーモン（オブジェクトの受け入れ／配信）、ノンスに紐付けられた検索可能性証明チャレンジ、体系的 Reed-Solomon 消失訂正符号（k=1 の場合は複製）、検索可能性証明の合格を条件とするバイト単位のストリーミング課金（ServiceType::Storage）、ケイパビリティで制御される取得（AccessPolicy + 任意の機密シール）
tenzro-cluster	モデル、ストレージ、データベースの配信で共有される、エンジンに依存しないローカルネットワーククラスター基盤：到達可能性ティア、プローブで測定したリンクコストグラフ、決定論的な最近傍順序付け、HRW ランデブー配置。すべての関数が測定入力に対する決定論的な関数であるため、メンバーはコーディネーターのラウンドなしに同じプランへ収束します
tenzro-database	マネージドデータベースプロトコルレイヤー（エンジン非依存、ドライバーなし）：DatabaseDescriptor、ローカル／LAN クラスター／ネットワークの各ティアへの配置、エンジンカタログ（PostgreSQL、Qdrant、Milvus、Valkey、Dgraph、Lance、Tantivy）。5 つのエンジンにドライバーがあります（PostgreSQL / Qdrant / Valkey はオペレーターが実行するエンジンに接続する薄いステートレスクライアント、Lance / Tantivy はプロセス内に組み込み）。Milvus と Dgraph はドライバーが連携されるまでカタログのみです。エンジンごとの構成検証、AccessPolicy + 機密シール、マネージド接続クレデンシャル、tenzro/databases ゴシップ
tenzro-bridge	クロスチェーン：Wormhole NTT（Guardian クォーラム検証器）、LayerZero V2、Chainlink CCIP + CCT、deBridge DLN、Li.Fi、Canton DAML、Hyperlane V3（ソブリン Tenzro-ISM）、Axelar GMP（Cosmos / Move / Stellar への到達）、Babylon Bitcoin ステーキング
tenzro-events	リプレイ、Webhook、WebSocket に対応するイベントソーシングおよびサブスクリプションシステム
tenzro-workflow	マルチパーティーワークフローランタイム：Canton DAML レシート、オンチェーントランザクションセレクター 0x01000040–0x0100004B をオーケストレーションします
tenzro-wasm	サンドボックス化されたエージェントスキルと MCP ツール向けの WASI 0.2 コンポーネントホスト：言語非依存、ケイパビリティベース、決定論的な燃料計測、コンテンツアドレス方式のコンポーネント ID
tenzro-node	フルノードバイナリ：JSON-RPC（932 メソッド）、MCP（535 ツール）、A2A（40 スキル）、Web API
tenzro-cli	CLI ツール：対話モードと完全な RPC カバレッジを備えた 108 個のコマンドモジュール

クイックスタート

Homebrew からインストールする

brew tap tenzro/tap
brew install tenzro

ソースからビルドする

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

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

ネットワークに参加する

# 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

ノードを実行する

# 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

独自のネットワークを実行する

# 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>

プロバイダーになる

GPU、クラスター、またはデータセンターを持ち込み、ネットワーク需要から収益を得ましょう。 ノードが実行中（tenzro-node --roles ai）であれば、1 つのコマンドですべてを処理できます。

tenzro join --provider

ハードウェアの検出、ウォレットの準備、フォーセットからの資金調達、モデルプロバイダーの段階で必要となる 1,000 TNZO の計算ボンド、プロバイダー登録、デフォルトの料金設定、そしてお使いのマシンに適合する最大のカタログモデルの取得とサービングは、すべて自動で行われます。お客様の容量はプロバイダーのゴシップトピックで通知され、推論の需要がお客様にルーティングされると、呼び出しごとに TNZO で決済されます。

AI 推論

# 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

プロトコルサーバー

ノードは 4 つのプロトコルサーバーと、6 つのエコシステム MCP サーバーを公開します。

コアサーバー

サーバー	ポート	プロトコル	エンドポイント
JSON-RPC	8545	HTTP	31以上の名前空間にまたがる932のメソッド（EVM互換機能とTenzro拡張機能。予測、ビジョン、テキスト埋め込み、セグメンテーション、検出、音声、動画などのマルチモーダルAI、生成メディア、MoEシャード型サービング、LANクラスタリング、マネージドデータベース、アプリホスティング：サイト、関数、マシン、リース、CAIPディスカバリー、EIP-7702委任、Permit2、Secure-Mint、Capital Intent、Workflowを含む）。同じリスナーは、OpenAI互換のHTTPルート/v1/chat/completions、/v1/responses、およびHTTP 402で保護された/api/paid/chat/completionsも提供します
Web API	8080	REST	検証（/verify/*）、/status、/faucet、/health、/chat、/providers、/discovery/resources、OAuthトークン／イントロスペクト／取り消し、パスキーウォレット
MCP	3001	Streamable HTTP	535個のツール + OAuth 2.1
A2A	3002	JSON-RPC + SSE	40個のスキルを備えたエージェントカード、タスクストリーミング

エコシステムの MCP サーバー

サーバー	ポート	ツール	対応範囲
Solana	3003	14	Jupiter スワップ、SPL トークン、Metaplex NFT、Bonfida SNS
Ethereum	3004	17	Chainlink フィード、ENS、ERC-8004 エージェント、EAS アテステーション
Canton	3005	23	DAML コントラクト、CIP-56 トークン、DVP 決済、ユーザー／パーティー管理、IDP 管理
LayerZero	3006	21	V2 メッセージング、OFT、Stargate、Value Transfer API
Chainlink	3007	21	CCIP、データフィード／ストリーム、VRF v2.5、自動化、Functions
LI.FI	3008	9	クロスチェーン集約、ルーティング、ガス見積もり

認証（段階式）

• パブリックツール（認証不要）：get_node_status、list_models、get_balance、resolve_did、debridge_search_tokens など。
• 書き込みツール（認証必須）：send_transaction、create_wallet、stake_tokens、register_identity など。
• 認証方式：OAuth 2.1 + DPoP（RFC 9449）。tenzro_onboardHuman／tenzro_onboardDelegatedAgent／tenzro_onboardAutonomousAgent を介して発行されるベアラー JWT を使用します。各リクエストには Authorization: DPoP <jwt> と、新しい DPoP: <proof> ヘッダー（リクエストごとの JWS-compact。RFC 7638 に従い、JWT の cnf.jkt サムプリントにバインドされます）が含まれます。RAR スコープ（RFC 9396）により、JWT の使用対象となるツールと金額が制限されます。
• API キー（オペレーター発行）：RPC オペレーターが tenzro_createApiKey（管理者トークンによる制限あり）を介して発行する tnz_... キーを、X-Tenzro-Api-Key として提示します。スコープにより、サードパーティの有料リソースを参照するメソッドへのアクセスが制限されます。対象となるスコープは、canton（Canton JSON Ledger API）、chainlink（Chainlink Data Feeds 用の Ethereum メインネット RPC クォータ + ブリッジ手数料オラクル + アダプターごとのスポンサーシップ）、および該当する機能を収益化するオペレーター向けの evm／svm／inference／tee／bridge です。テナントごとのカウンターは CF_CANTON_ANALYTICS + CF_BRIDGE_ANALYTICS に記録されます。chainlink スコープのメソッドには GCRA レート制限が適用されます。
• 失効：tenzro_revokeJwt（jti を指定して単一トークンを失効）または tenzro_revokeDid（アクトチェーンをたどって連鎖的に失効）。
• 設定：TENZRO_MCP_AUTH=tiered（デフォルト）| false（開発用）| full（すべてのツールで認証必須）

主な機能

マルチVM実行 — 3つのVM、1つのステートマシン

1つのVMを選ぶチェーンでは、すべてのワークロードをそのVMに合わせる必要があります。Tenzroは3つのVMを実行し、トランザクションの種類に応じてルーティングします。3つすべてが同じ状態、同じガストークン（TNZO）、同じTDIPアイデンティティ、同じコンセンサスを共有します。

• EVM — 流動性とコンポーザビリティ。 Ethereumのサーフェスは、既存のコントラクトとツールの最も広範なプールを対象としています。Tenzroは、標準のすべてのプリコンパイル（ecRecover、SHA-256、RIPEMD-160、Identity、ModExp、EC_ADD、EC_MUL、EC_PAIRING、BLAKE2F）を正規のEIPに従って備えたrevmに加え、コンセンサスグレードの署名集約をネイティブに行う7つすべてのBLS12-381プリコンパイル（EIP-2537）を組み込んでいます。Block-STMは、MVCC並行制御と、競合発生時の自動的な逐次フォールバックによって、並列トランザクション実行を実現します。EIP-1559の動的手数料市場では、基本手数料がバーンされます。ネイティブプリミティブは、プロトコルを認識するプリコンパイルによってEVMを拡張します。TEE_VERIFY（ベンダー証明書チェーンの検証を伴うハードウェアアテステーション）、ZK_VERIFY（オンチェーンのPlonky3レジストリに対するO(1)コミットメント照会）、VRF_VERIFY（RFC 9381 ECVRF）、IBC_VERIFY（IBC-Eurekaライトクライアント照会）、Tenzroのプリコンパイル群（TNZO_BRIDGE、TOKEN_FACTORY、CROSS_VM_BRIDGE、STAKING、GOVERNANCE、NFT_FACTORY、MODEL_INFERENCE、SETTLEMENT、0x1021のグローバル供給量会計、0x1022のモジュールレジストリ）、ERC-4337 v0.8アカウント抽象化、EIP-7702 Type-4委任、witnessバインディング付きPermit2 SignatureTransfer、およびERC-7579のモジュラーバリデーターモジュール（ソーシャルリカバリー／セッションキー／支出上限／WebAuthnパスキー／TEEバインド）を提供します。
• SVM — スループットとレイテンシー。 Solanaのサーフェスは、1秒未満のファイナリティと高いスループットが必要なワークロード（DEXルーティング、エージェント間のマイクロペイメント、即時決済）を対象としています。Tenzroは、Anzaのsolana-svmのTransactionBatchProcessorを組み込んでいます（svm-full cargo機能の背後にあります）。これによりSolana SBFプログラムを変更せずに実行できます。この機能がない場合も、SPL Tokenアダプター、クロスVMネイティブプログラム、PDA導出は引き続き動作し、SBFパスはVmError::SvmFullFeatureRequiredを返します。SPL Tokenプログラムは、ネイティブの統合トークンレジストリにマッピングされます。SVM上のスワップは、EVM上の送金と同じ残高領域で決済されます。2つのVM間にブリッジはありません。
• Canton DAML — プライバシーと機関投資家向け決済。 Cantonは、トークン化された現金、マネー・マーケット・ファンド、債券、株式、国債、OTCデリバティブを、機関投資家向け金融システムがすでに決済している場所です。TenzroはCanton 3.5以降のJSON Ledger API v2を直接利用します。CIP-56のCanton Coin保有分はTNZOと相互変換でき、CIP-26のユーザー管理では、各テナントを個別のパーティーに紐付け、CanActAs権限をサーバー側で強制します。DARのアップロード、パーティーの割り当て、コマンドの送信、アクティブコントラクトの照会はすべて、EVMやSVMの呼び出しと同じノードAPIサーフェスから利用できます。Cantonのプライバシーモデルでは、トランザクション本体は署名者にのみ公開されます。TenzroはクロスVMオーケストレーションとパブリックコミットメントを提供します。
• クロスVMトークンモデル — Sei V2ポインター。 TNZOには、唯一の正規のネイティブ残高があります。EVM側のwTNZO ERC-20ポインターとSVM側のwTNZO SPLアダプターは、同じ基盤残高を共有します。両者間にブリッジはなく、ラップ／アンラップの区別も、流動性の分断もありません。Canton CIP-56の保有分は、Cantonブリッジアダプターを介して相互変換できます。アプリケーションから見ると、ウォレットは最後に利用したVMにかかわらず、単一のTNZO残高を持ちます。
• これらを組み合わせると。 トークン化された国債（Canton）とステーブルコインによる支払い（EVM）のDvPを決済するエージェントは、1つのアイデンティティを通じて、全体を1つのワークフローとして実行します。SolanaのDEXスワップの代金を支払い、その領収をTenzroのコンセンサスに記録するエージェントは、1つのTNZO残高でそれを行います。クロスVMの連携はアプリケーションコードではなく、ワークフローのプリミティブです。

分散型AIインフラストラクチャ

プロトコルレイヤーでは、AIコンピューティングを集中型サービスではなく、協調して利用するリソースとして扱います。 Tenzro は独自のモデルを提供していません。 この README の各所で名前が挙がっているすべてのモデル（Qwen、DeepSeek、GLM、Kimi、Gemma、MiniMax、FLUX、Wan、LTX、SAM、CLIP、Whisper など）は、ネットワークが サポートする サードパーティ製チェックポイントであり、独自開発または独自所有のモデルではありません。サービング経路はモデルに依存しません。load_model は GGUF パスを受け取り、llama.cpp はファイル自体のメタデータからアーキテクチャを判別します。そのため、ModelArchitecture 列挙型は（表示とフィルタリング用の）情報であり、許可リストではありません。カタログに登録されていないモデルも、ドキュメントに記載されたデフォルト設定でサービングできます。

厳選されたカタログが提供するのはメタデータと利便性であり、利用許可ではありません。カタログの各エントリーは、HuggingFace にログインしなくてもダウンロードできる アクセス制限なし のモデルとして選ばれています。そのため、新しいノードはオペレーターがアカウントを持っていなくても、モデルを取得してサービングできます。

モデルごとの設定は、単一の固定スキーマではなく、プラグイン可能です。 モデルごとに必要なものは実際に異なります。共通項だけに絞った設定では、要件の厳しいモデルが動作しないか、単純なモデルに余計な負担をかけることになります。そのため、カタログの各エントリーにはデフォルト値を持つオプションの項目があり、モデルには該当するものだけを宣言します。たとえば、マルチモーダルプロジェクター（mmproj）は搭載モデルのみ、ドラフトモデルと MTP 種別の組み合わせは投機的デコーディングに対応するモデルのみ、MoeShape はスパースモデルのみ、デフォルト設定がそのモデルファミリーに適さない場合はサンプリング用の ServingProfile、モデルに思考モードがある場合は ReasoningPolicy を指定します。モデル独自のチャットテンプレートに上流側の不具合がある場合、TemplateFix でベンダー管理の代替テンプレートを指定します。カタログが宣言するのは どの 修正を使うかであり、推論クライアントがファイルを提供します。ランタイムでモデルを特別扱いするわけではありません。指定されていない項目はすべて、ドキュメントに記載されたデフォルト値にフォールバックします。そのため、カタログにない GGUF もサービングできます。生成メディアでも同じ構成になっており、エントリーにはパイプラインごとのピクセルステップ単価、エキスパート分割境界、フレーム上限が含まれます。モデルによっては、汎用パスではなく、特定の上流バージョンに固定された作成済み設定を通じてサービングされます。

カタログへの登録は、モデルがエンドツーエンドで検証済みであることを意味しません。 レジストリには、実際のハードウェアで動作確認されていないモデルも含まれており、その点を偽ることはありません。テストは継続中です。モデルに汎用経路では対応できない要件（修正済みチャットテンプレート、異なるサンプリングデフォルト、フレーム上限、固定された上流バージョンなど）が見つかった場合は、そのモデルを実行するのに必要な任意項目を新たに追加し、必要としない他のモデルでは未設定のままにします。実際のチェックポイントに必要なものに応じて設定項目が増えていくよう、設定の仕組みは事前に固定されたスキーマではなく、モデルごとに追加できる形になっています。動作に問題のあるモデルに遭遇した場合、それは報告すべき不足であり、設計上の制限ではありません。

アクセス制限付きモデルもサポート対象ですが、各自の認証情報が必要です。 有力なオープンチェックポイントの中にはアクセス制限付きのものがあります。情報の閲覧は無料でも、ダウンロードにはアカウントごとの承認が必要です（FLUX.2-dev と klein-base-9B の系列は Hub で gated: auto に設定されており、Llama の GGUF も同様です。Llama がデフォルトのカタログエントリーに含まれていない理由はこれだけです）。利用するには、HuggingFace で利用規約に同意し、ノードに自分のトークンを渡してください。HF_TOKEN、HUGGING_FACE_HUB_TOKEN、または huggingface-cli login がすでに書き込んだ ~/.cache/huggingface/token のいずれかを指定できます。3 種類すべてが読み込まれるため、通常の方法でログイン済みのオペレーターは、ほかに何もする必要はありません。このトークンはオペレーター自身のアカウント用の認証情報です。huggingface.co にのみ送信され、ノードには保存されず、ログからもマスキングされます。トークンがない場合、アクセス制限付きモデルの取得は 401/403 エラーで失敗し、エラーメッセージにはリポジトリと、同意すべき利用規約のページが正確に示されます。tenzro status はトークンの有無を報告します。そうしないと、認証情報の欠落が説明のないダウンロード失敗としてしか表面化しないためです。

• 分散型 Mixture-of-Experts サービング。 MoE モデル（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 / K3 2.8T-A104B、MiniMax M3、Gemma 4 26B-A4B）は、2 つのモードでサービングされます。1 つのプロバイダーのハードウェアにモデルが収まる場合は、完全レプリカを使用します。収まらない場合は、分散型エキスパートシャードを使用します。プロバイダーは ProviderCapacity.moe_holdings で保持するエキスパートを宣言し、ディスパッチプランナーはトークンごとの top-k ルーティング判断をホルダーごとのバッチに集約して、ホルダーの iroh QUIC エンドポイントへ直接ディスパッチします。シャードビューは既存のプロバイダーレジストリから派生したビューです。MoE プロバイダーも、密モデルをサービングするネットワークプロバイダーと同じです。レプリケーションはガバナンスで調整でき（デフォルトではエキスパートごとにホルダー 2 つ以上、人気の高いエキスパートでは最大 8 つ）、型付きパイプラインロールには Replica、Router、ExpertHolder、PrefillDecode、Prefill、Decode があります。実行はノード内で行われます。MoeExpertRuntime はエキスパートごとの FFN 重み（ExpertFfn）とゲーティングネットワーク（GatingNetwork）をホストし、safetensors（ローカルファイルまたは iroh-blobs 経由の tenzro://blob URI）から読み込みます。フォワードパスではローカルでゲーティングを行い、エキスパートのサブバッチを tenzro/moe iroh ALPN（HTTP フォールバックあり）経由でホルダーに振り分け、重み付きエキスパート出力を結合します。ホルダーはメモリに収まる数を超えるエキスパートを広告できます。ランタイムは、バイト数に上限のあるメモリ階層 LRU（MemAvailable の 60％を自動的に予算として設定し、取得できない場合は 4 GiB）にエキスパートを保持し、ディスク階層に生の safetensors を退避して、必要に応じてオンデマンドでデコードして戻します。また、先読み機能により、バッチ到着前にフォワードパスで使う予定のディスク階層エキスパートを昇格させます。常駐状態（メモリ上の Warm / ディスク上の Cold）はライブの階層状態から読み取られるため、シャードマップには実際に読み込まれている状態が反映されます。エキスパートの射影計算（Y = X·Wᵀ）は ExpertCompute シームの背後で実行されるため、同じフォワードパスでホルダーが利用できるハードウェアを使えます。CPU の ndarray パスは常に利用可能で、対応する x86 では実行時に検出される AVX-512-VNNI Q8_0 ドット積パスも使えます。一方、GPU バックエンドは cargo 機能を有効にした場合にのみコンパイルされます（NVIDIA の cuBLAS grouped-GEMM 用の moe-cuda、ベンダーを問わない WGSL カーネル用の moe-wgpu。moe-gpu は両方を有効にします）。デフォルトビルドには含まれません。ホルダーは moe_gpu を広告し、ルーターは GPU ホルダーにエキスパートの配置を優先します。エキスパートはブロック量子化して、保存する blob とホルダー間で移動するバイト数の両方を減らせます。対応形式は Q8_0（約 1 バイト／重み）、Q4_K（約 4.5 bpw）、Q6_K（約 6.6 bpw）です。バランスの取れたデフォルトは ExpertQuantPlan::q4_k_m（gate/up は Q4_K、down は Q6_K）で、行単位で逆量子化します。ホルダー間ディスパッチでは、hidden dim が 32 の倍数の場合にアクティベーションを Q8_0 ブロックに圧縮します。低速または応答しないホルダーがある場合は、ウォーム状態のバックアップホルダーに再ディスパッチし、ホルダーからの応答をコンバイナーへストリーミングします。期待される寄与が 1 つでも届かない場合、コンバイナーは明示的に失敗します。プランニング RPC：tenzro_moeShardMap、tenzro_moePlanDispatch、tenzro_moeReplicationPolicy、tenzro_moeCatalogShape。実行 RPC：tenzro_moeExpertLoad、tenzro_moeGateLoad、tenzro_moeExpertUnload、tenzro_moeGateUnload、tenzro_moeExpertStatus、tenzro_moePrepareExperts、tenzro_moeRoute、tenzro_moeExecute、tenzro_moeForward。CLI：tenzro moe {shard-map, plan-dispatch, replication-policy, catalog-shape, load-expert, load-gate, unload-expert, unload-gate, prepare-experts, status, forward}。
• LAN クラスタリング — 層ごとのパイプライン並列処理。 どの単一メンバーにもモデルが収まらない場合、同じ LAN 上の複数のマシンがパイプラインとして連携してサービングします。モデルの層を連続したステージに分割し、メンバーごとに 1 ステージを割り当てます。隣接するステージ間でネットワーク越しに送るのは、境界アクティベーション（トークンごとに hidden_dim × dtype_bytes、fp16）のみです。配置は決定的です。VRAM の重みを考慮した最大剰余法による層の割り当て、最近傍法による貪欲なステージ順序付け、データプレーンリンクを確立できないメンバーを除外する到達可能性ゲートを使い、モデルはホットパスで使いません。メンバー間で同じランタイムビルドコミットを共有する必要があり、ワイヤーバージョンのネゴシエーションはありません。メンバー間でバックエンドが異なっていてもかまいません。RPC tenzro_clusterPlan は適合判定を返し、クラスタが形成される場合はメンバーごとの順序付き層ステージも返します。サービングはパイプラインを自動的に起動します。tenzro_serveModel はモデル形状を調べるため GGUF ヘッダーを読み取り、ゴシップされた ClusterProfile アナウンスからメンバーを検出し、1 台のホストにモデルが収まらない場合はクラスタを実行します。1 台のホストで処理するには force_single を指定し、検出結果を上書きするには cluster_members を指定します。
• ローカル優先の検出とルーティング。 ノードは mDNS を介して自身の LAN セグメント上のピアを検出し（tenzro_localPeers）、継続的な接続性ティア（direct / relay_only / unreachable）を公開します（tenzro_nodeReachability）。実行リゾルバーはローカルプロバイダーを優先し、到達可能なプロバイダーがない場合のみ広域ネットワークにフォールバックするため、同じ LAN 上のマシンが処理するリクエストは LAN の外に出ません。各ノードはハードウェアの自己プロファイル（ランタイムビルドコミット、CPU アーキテクチャ、OS、検出されたコンピュートデバイス、そこから導出されたサービング容量／バックエンド／機能キー）も公開し（tenzro_nodeProfile）、単一マシンでの適合判定とクラスタ計画の両方に利用します。
• マルチトークン予測（MTP）による推測的デコード。 インプロセスランタイムは推測的デコードを実行します。ドラフターが候補トークンのブロックを提案し、ターゲットがそれらを 1 回のバッチデコードで検証し、受理された先頭部分によってストリームを進めます。モデルのサービング時にドラフターを自動的に読み込みます。tenzro_serveModel はカタログの drafter_id を読み取り、ディスクから読み込むか、バックグラウンドでダウンロードし、結果を serve 応答の mtp フィールドで報告します。モデルが候補を生成する方法は 2 通りです。小型のペア型ドラフターチェックポイントを使う方法、またはターゲット自身の隠れ状態に基づいて候補を生成するネイティブ組み込み MTP ヘッドを使う方法（drafter_id は未設定、mtp_kind: DraftMtp）です。後者では別のチェックポイントをダウンロードする必要はありません。DeepSeek V3（ネイティブ、受理率約 80％、デコード速度約 1.8 倍）、DeepSeek V4 Pro / Flash、GLM 5.2、Gemma 4（全サイズ）、Qwen 3.5（0.8B/2B/4B/9B/27B/35B-A3B/122B-A10B/397B-A17B）、Qwen 3.6 27B + 35B-A3B、Qwen 3.8 27B（ネイティブ組み込みヘッド）で宣言されています。プロバイダーは ProviderCapacity.mtp_enabled でドラフターの同時読み込みに対応していることを広告します。draft_n が設定されている場合、推論ルーターは MTP 対応リクエストを MTP 対応プロバイダーに絞り込みます。
• インプロセスで動作するビジョン対応言語モデル。 マルチモーダルプロジェクター（mmproj）を含む GGUF は、言語モデルの重みとともにプロジェクターを読み込みます。そのため、画像添付ファイルは別のビジョンサービスに送られるのではなく、同じランタイム内でエンコードされ、プロンプトに挿入されます。カタログエントリーでは MmprojSpec を使ってプロジェクターを宣言します。この機能は mtmd cargo 機能を有効にしてコンパイルします。
• 難易度を考慮したルーティング。 宣言されたメタデータ（パラメーター数、コンテキストウィンドウ、機能タグ）に基づくモデル選択では、特定のプロンプトが高コストなモデルを必要とするかどうかは分かりません。プロンプトは埋め込みを生成され、必要に応じて拡張されるオンライン逐次 k-means マップでグループ化されます。学習コーパスもオフラインでの適合も不要です。各モデルには、実際のサービング結果からクラスタごとの結果カウンターが蓄積されるため、プロンプト近傍ごとのモデルの強みは測定可能な値になります。新しく登録されたモデルは中立的な事前分布に楽観性ボーナスが加わった状態で開始し、探索対象であり続けます。クラスタマップとカウンターは CF_MODELS に永続化され、起動時に読み込まれます。
• ネットワークモデルカタログ。 プロバイダーは、モダリティ、機能、コンテキスト長、プロバイダー自身が設定した価格、サービングスケジュール、有効期間（TTL）、サービングアドレスを含む署名付きモデルオファーを tenzro/models 上でブロードキャストします。ノードは各アナウンスを検証し、(model_id, provider) のペアごとに署名鍵を固定して、期限切れでないオファー一式をインテントルーティングに渡します。これにより、ルーティングはローカルの運用者が登録したモデルだけでなく、ネットワーク上のすべての有効なオファーを評価し、決済の分配先は落札オファーに記載された受取人になります。
• 分散型トレーニング — Tenzro Train。 外側の同期処理を分離したデータ並列プロトコルです。Rust プロトコルレイヤー（tenzro-training）は、同期器のステートマシン、5 つの集約ルール（Mean / LoraAlternating / TrimmedMean / CoordinateMedian / Krum）、Nesterov 外側オプティマイザー、フラグメントコミットメント、トレーニングレシート、オンチェーンの実行ルートコミットメントを管理します。Python リファレンストレーナーは、モダリティ別の内側ループ（transformers、ネイティブ PyTorch、gluonts、timm）向けに PyTorch FSDP2 + Hivemind + safetensors をラップします。k-of-N 証人委員会は、冪等な確定処理と非承認証明書によって、リージョンをまたぐ複数の同期器間の調整を担います。通信効率を高める仕組みとして、ブロック単位の対称勾配量子化（Int8 は 4 倍、Int4 は f32 より約 8 倍小さく、Rust／Python のコーデックはバイト単位で同一）、ストリーミング同期（各ラウンドで同期するパラメーターシャードは 1 つのみ、active_shard = round % num_shards）、適用の遅延（ラウンド r の外側更新はラウンド r+1 中に適用され、通信と計算が重なる）、ペアごとのコサイン勾配一致度に応じてスケーリングする適応型外側学習率、1 台のトレーナーには大きすぎるモデル向けのパイプライン並列トレーナーグループがあります。内側オプティマイザーはタスクごとに選択できます（inner_optimizer：muon / adamw / sgd）。Muon は Newton-Schulz 反復によって 2D 重み更新を直交化します。機密ティアでは、エンクレーブ内のトレーナーにシャードごとのデータ鍵を渡す際に、HPKE RFC 9180 base-mode でラップします（データの封印を解除できるのはトレーナーの TEE 内だけです）。信頼ティアは 3 つあります。Open（Mean と LoraAlternating）、Verified、Confidential です。
• 拡散モデルによるメディア生成 — Tenzro Media Gen。 4 種類のジョブ（text2image、image2image、text2video、image2video）に対応した、ネットワークリソースとしての画像・動画生成です。Rust プロトコルレイヤー（tenzro-media-gen）は、ジョブキュー、ワーカーレジストリ、ピクセルステップ料金、支払いの分配、3 種類の署名用プレイメージ、コンテンツアドレス方式のペイロードストアを管理します。Python リファレンスワーカー（integrations/media_gen/、HuggingFace diffusers）が管理するのはノイズ除去ループだけです。事前設定済みカタログエントリーはすべてサードパーティーのチェックポイントです。Qwen-Image とその 4 ステップ蒸留版、Qwen-Image-Edit、Z-Image-Turbo、FLUX.2-klein、Wan 2.2 動画ファミリー、LTX のいずれも Tenzro 独自のモデルではありません。ピクセルステップ料金の形式、分割エキスパートの境界、フレーム制限などのメタデータがあらかじめ設定された状態で提供されるパイプラインです。ワーカーは実際に保持しているパイプラインを広告するため、これらは出発点であり、上限ではありません。登録時には、運用者がライセンスティアへの同意を済ませていないモデルは拒否されます。また、ゲート付き重みには前述のとおり運用者自身の HuggingFace トークンが必要です。分割エキスパートによるレンダリングは、トランスフォーマーが高ノイズ／低ノイズのエキスパートのペアで構成されるモデルに対応します。固定ノイズしきい値（t ≥ boundary_ratio × num_train_timesteps）で各ステップを担当するエキスパートを決定するため、モデル全体では 80 GB 必要なところ、片方のエキスパートは 48 GB に収まります。両半分の間でやり取りする中間潜在表現は 1 つだけで、支払いは後から各ワーカーが申告する値ではなく、署名付き引き継ぎ情報から取得した steps_completed / total_steps に基づいて分割されます。出力、潜在表現、条件付け画像はすべて tenzro://blob/ でアドレス指定され、読み込み時に検証されます。RPC は tenzro_mediaGen_* 配下です。CLI：tenzro media-gen {catalog, quote, post-job, get-job, get-receipt, fetch-output, enroll-worker, claim-job, publish-output, record-handoff, submit-receipt, fetch-latent}。
• Cortex。 別個のコンピュートレーンとして公開される、再帰的深さトランスフォーマーの推論ワーカーです。HTTP サイドカーアーキテクチャ、署名付きレシート、アテステーションスイート、ゴシップベースのワーカー検出、深度に応じた料金設定を備えています。
• 機密推論。 モデルプロバイダーは推論を Intel TDX / AMD SEV-SNP / AWS Nitro / NVIDIA GPU CC エンクレーブ内で実行できます。結果ハッシュはエンクレーブにバインドされた鍵で署名され、アテステーションチェーンはオンチェーンの TEE_VERIFY を通じて検証されます。

分散型アプリケーションのホスティング

静的サイト、サーバーサイド関数、または変更されていない常駐サーバーを Tenzro ノードに公開し、手動での TLS、DNS、Caddy、ポート設定なしでパブリックインターネット経由で提供できます。3 つのランタイムクラスは、deploy → discover → place → serve という共通の流れを使用します。

• 静的サイトとシングルページアプリ。 サイトは、リクエストパスをノードの iroh ストアにあるコンテンツアドレス指定されたブロブ（tenzro://blob/<hash>）にマッピングする、署名付きルートマニフェストです。コンテンツがファイルシステムに触れることはありません。リクエストパスはルートマップのインデックスとしてのみ使用されます。SPA フォールバックでは、アセット以外のパスに対してインデックスを 200 で返します（アセットが見つからない場合は直接 404 を返すため、バンドルチャンクの欠落が隠されることはありません）。レスポンスには ETag（ブロブのハッシュ）が付与され、If-None-Match による 304 に対応します。RPC tenzro_siteDeploy ／ CLI tenzro site deploy。
• 関数。 サンドボックス内でリクエストに直接応答する wasi:http コンポーネント（WASI 0.2、wasi-skills 機能のもとで wasmtime 上でホスト）。権限は機能ごとに制御され、燃料計測は決定論的で、リクエストごとの実時間期限が設定されます。RPC tenzro_functionDeploy ／ CLI tenzro function deploy。
• マシン。 変更されていない Node ／ Python ／ Rust サーバーを実行する Firecracker マイクロ VM 内の常駐プロセス（firecracker 機能のもとで、KVM とネステッド仮想化を備えたオペレーターノード上で動作）。RPC tenzro_machineDeploy ／ CLI tenzro machine deploy。
• 配置と経済性。 プロバイダーが提示する時間単位の価格が入札額です。デプロイ時には、対応可能なノードを検出し、ランタイムクラス ／ CPU ／ RAM ／ ディスク ／ TEE ／ 価格上限で厳密に絞り込んだうえで、まずリージョン、次に価格の安さの順にランク付けし、上位 N 個の異なるノードをリースします。リースは台帳上の LeaseRecord として記録され、tenzro_listLeases ／ tenzro_getLeasesForApp（CLI tenzro lease list ／ tenzro lease get）から確認できます。配置はベストエフォートです。対応可能なリモートノードがない場合、アプリはローカルで提供されるため、デプロイが失敗することはありません。30 秒ごとの調整処理で、期限切れのリースを一掃し（プロバイダーのアナウンスの TTL の古さを稼働状況のシグナルとして使用）、応答がないノードのレプリカを稼働中のノードに再配置して、レプリカ数を維持します。デプロイ時のフラグ：--replicas、--region-hint、--max-price-per-hour。
• オペレーター設定のエッジ。 各オペレーターは、エッジがアプリを提供するドメインを設定します。ネットワーク全体で共通の正規ホストはありません。ホスト名エイリアスは、受信リクエストをアプリの提供パスに書き換えます。エッジは tenzro/http トランスポート（HTTP リクエストごとに QUIC 双方向ストリームを 1 つ使用）経由で配置先ノードに転送し、レスポンスをストリーミングで返します。エッジの TLS は PQ ハイブリッド方式で、自動的にプロビジョニングされます。名前付け、配置、変更のすべてに、所有者 DID の管理権限を証明する署名付きエンベロープが必要です。

RPC と CLI の全項目については、docs/HOSTING.md を参照してください。

テナントのファイルストレージ

/v1/files の背後にあるマルチテナントのオブジェクトストレージです。コンテンツアドレス型ストレージプロバイダーを置き換えるのではなく、その上に構築されています。プロバイダーは、呼び出し元が割り当てた ID でオブジェクトを識別し、シャードからそのバイト列を再構築できます。一方で、あるオブジェクトが「火曜日にアップロードされた、Alice の notes.txt」であることは意図的に認識しません。それはアプリケーションのメタデータであり、シャード層に持ち込むと、シャードを保持するすべてのプロバイダーが、その断片のファイル名と所有者まで持つことになります。そのため、命名レイヤーはテナントがアップロードしたノード内にとどまり、ストレージ層が保持するのはバイト列のみです。

アップロードは 4 個のデータシャードと 2 個のパリティシャードに消失訂正符号化されます。これにより、プロバイダーが同時に 2 つ失われてもデータを保持でき、独立したプロバイダー間に分散されます。ストリーミングストレージ契約がその費用を賄います。アップロード結果の deal_id が null の場合、バイト列の保存は完了していますが、それを保持する費用は支払われていません。

分離は各操作で適用されます。特に重要なのは一覧表示です。取得、内容の参照、削除はいずれも既知の単一 ID を指定するため、そこで所有権チェックを怠ると、ID をすでに推測した人にファイルが 1 つ漏れるだけです。一方、list はファイルを列挙します。他のテナントのファイル ID を検索した場合は、そのファイルが存在しない場合と同じように報告されます。削除すると参照が解除され、契約も停止しますが、シャードは消去されません。シャードが期限切れになるのは、保持費用の支払いが止まった後だけです。そのため、削除を秘匿化として扱ってはいけません。RPC は tenzro_uploadFile / tenzro_listFiles / tenzro_getFile / tenzro_deleteFile、CLI は tenzro files {upload, list, get, download, delete, usage} です。

レンタルハードウェアセッション

オペレーターがノードを貸し出す場合、借り手はノードの RPC 経由だけでなく、ハードウェアを直接使える必要があります。モデルは GCP OS Login + IAP や AWS SSM Session Manager のように、ID に紐づき、有効期間が短く、受信ポートが不要で、接続元から失効でき、監査可能なものです。root SSH キーを渡す方式ではありません。認可と隔離はノード内で行われ、トランスポートには tenzro/shell iroh ALPN を使用します。

セッションは 3 つの要素で制御され、それぞれ異なる問いに答えます。オペレーターが発行するか、レンタルのデポジットが入金されたときに自動発行されるサービスキーは、呼び出し対象の どのリースか を特定します。サービスキーだけでは、誰かが文字列を渡されたことしか証明できません。呼び出し元の Tenzro ウォレットを使ったパスキー認証（ウォレットがすでに実行しているブラウザー起動フローです。CLI がリンクを表示し、ユーザーがブラウザーで認証し、CLI が結果をポーリングします）により、セッションをキーの所持者ではなく、個人のウォレット に紐づけます。そして、リースの認可済みウォレットリストへの登録により、キーが漏えいしても、それだけでは使用できないようにします。

リースは利用範囲も定めます。対象のアクセラレーター、コア数、メモリ容量、送信エグレスを許可するかどうか（デフォルトではオフです。レンタルシェルは計算用であり、どちらの場合もオペレーターのローカルネットワークにはアクセスできません）、セッションごとの実時間上限（最大 12 時間）、およびリース期間です。アクセラレーターのリストを省略すると CPU のみのリースになります。「すべての GPU」は、誰も選択していない利用範囲だからです。リースを失効させると、そのリースに対する未終了のセッション許可はすべて無効になります。CLI は tenzro shell login および tenzro shell lease {open, revoke, list} です。

3D アセット生成

画像から3Dへの変換は、画像や動画とは別ではなく、同じジョブキューに入ります。投稿、ジョブの取得、コンテンツアドレス指定された出力、署名済みレシート、ピクセルステップ単位の決済といった周辺の仕組みは同一です。異なるのはローダーと成果物だけで、カタログエントリーがその両方を保持します。

• 種類。 MediaGenKind に image23d と text23d が追加されます。出力はフレームではなく、PBR マテリアルを備えた GLB メッシュなので、後続処理で動画としてデコードされることはありません。
• プラグ可能なバックエンド。強制はありません。 メディア生成のエントリーでは backend を宣言し、デフォルトは diffusers です。このデフォルトにより、既存のパイプラインはすべてバイト単位で変更されずに保たれます。trellis2-4b は、Microsoft 独自の trellis2 パッケージを通じて読み込まれます。これは diffusers パイプラインではありません。これをシム経由で動かしたり、diffusers モデルを新しい抽象化に通したりすれば、動作する経路を均一な経路と引き換えにすることになります。バックエンドのパッケージがないワーカーは、そのエントリーへの登録を拒否し、ジョブを受け付けて取得時に失敗することはありません。
• 生成物に基づく料金設定。 3D ジョブの見積もりは、条件付け画像ではなくボクセルグリッドに基づきます。width／height は 入力写真 を示すため、これらに基づいて料金を設定すると、アセットを無視して入力に課金することになります。同じ写真から生成する 512³ と 1536³ のジョブは、処理量が 27 倍異なるのに、同額になってしまいます。料金はグリッドの一辺（r²）に基づきます。生成コストは空の内部ではなく、疎に占有された表面に応じて増えるためです。また、同じ per_pixel_step レートを適用することで、どちらも同じ経路で決済できます。

これらによって tenzro model serve や、すべてのピクセルパイプラインが変更されることはありません。

ノードの機能サーフェス

ノードでできることと、呼び出し元が見つけられることの隔たりを埋める機能が 2 つあります。

• 汎用 RPC ゲートウェイ。 ノードは約 900 の JSON-RPC メソッドを提供しており、リリースごとにさらに増えています。そのため、手作業で保守するクライアントリストは常に遅れ、開発者は必要なメソッドを使おうとしたときに初めてその不足に気づきます。tenzro_listRpcMethods は、ゲートクラス（管理者トークンが必要か、公開か）と必要な API キースコープを各エントリーに含むディレクトリをノード自体から返します。これにより、呼び出し元は先にエラーを発生させることなく、「異なるスコープのキーが必要」なのか「オペレーターのトークンが必要」なのかを区別できます。フィルターなしでは約 900 行になるため、名前空間または部分文字列で絞り込めます。見つかったメソッドは、名前を指定して呼び出せます。認可の仕組みは変わりません。ゲートウェイ経由の呼び出しにも、直接リクエストと同じ管理者トークンゲート、API キースコープゲート、デフォルト拒否の分類が適用され、提示された認証情報で許可されている範囲に限って実行されます。CLI（tenzro rpc {methods, call}）、両方の SDK、MCP、A2A から利用できます。
• モデルの可視性 — 3 つの階層。 モデルを呼び出せるユーザーは、モデルのプロパティによって決まります。network（デフォルト）では tenzro/models にモデルが通知され、料金を支払うすべての呼び出し元が利用できます。サービスキーも事前の関係も不要で、サービスキーゲートが有効なノードでも利用できます。gated では、オペレーターがポリシーに事前合意した API キーを持つ呼び出し元に提供しますが、意図的に通知しません。相手側はすでにモデルの存在を知っており、ゴシップで通知すると、利用できない呼び出し元にも容量を知らせることになるためです。private はノードの外に出ません。CLI は tenzro model serve [--gated | --private] です。公開モデルの例外は限定的です。現在 network で提供されているモデルに対する推論メソッドの許可リストに限られます。ゲート付きモデル、プライベートモデル、不明なモデル、その他のメソッドには、引き続きキーが必要です。
• 機能の可視性。 ノードが実行できることと、ノードが通知することは分離できます。オペレーターは、アンロードも無効化もせずに、個々の機能（ai、storage、database、hosting、rpc、tee、compute）の通知を停止し、後で再開できます。コンセンサスは意図的に非表示にできません。ピアから到達できないバリデーターは投票できないためです。CLI は tenzro visibility {show, hide, publish} です。

マルチモーダル推論

カタログには、7つの ONNX ランタイムと llama.cpp の言語処理経路が含まれています。これらは、型付きの InferencePayload（Chat / Forecast / VisionEmbed / VisionSimilarity / TextEmbed / Segment / Detect / Transcribe / VideoEmbed）に基づき、モダリティを考慮する InferenceRouter::route() によってすべて振り分けられます。ライセンス区分（Permissive（Apache/MIT/BSD）、Attribution（CC-BY-4.0）、CommercialCustom（DINOv3、SAM、Gemma — --accept-license が必要）、NonCommercial（--accept-non-commercial がない場合は拒否））によって登録が制御されます。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（均等にサンプリングしたフレームを用いるビジョンフォールバックエンコーダー）を利用できます。各モダリティは、JSON-RPC、MCP、A2A、および CLI サブコマンドを通じて公開されます。すべての ONNX ランタイムは、CPU にフォールバックする前にハードウェア実行プロバイダーを登録する共通のセッションビルダーを使用します。onnx-tensorrt / onnx-cuda / onnx-coreml の Cargo 機能を有効にすると、対応するプロバイダーがコンパイルされます（デフォルトの優先順位は TensorRT → CUDA → CoreML）。TENZRO_ONNX_EP 環境変数で優先順位を上書きできます。プロバイダーの登録に失敗した場合はエラーにせず、次のプロバイダーにフォールバックします。コンテナイメージの各バリアントには、対応するランタイムと組み合わせた LLM 高速化バイナリが含まれます。Dockerfile.cuda（NVIDIA CUDA — マルチアーキテクチャ対応で、Grace-Blackwell などの x86_64 および arm64 ホストをサポート）、Dockerfile.rocm（AMD ROCm）、Dockerfile.vulkan（ベンダーを問わない Vulkan）があります。ONNX GPU 実行プロバイダーが含まれるのは x86_64 CUDA イメージのみです。arm64 CUDA、ROCm イメージ、Vulkan イメージでは、ONNX モダリティは CPU にフォールバックしますが、llama.cpp の言語処理経路は引き続き GPU で高速化されます。バックエンドとイメージの全対応表については、docs/AI.md §2.7 を参照してください。

アイデンティティ（TDIP）— 4種類

• did:tenzro:human:{uuid} — KYC ティア。管理対象マシンと、任意の数の委任エージェントの管理者を持ちます。
• did:tenzro:machine:{controller}:{uuid} — 人、機関、または上流のマシンの代理として動作する委任エージェントです。委任スコープ（トランザクションごとの上限、日次上限、許可された操作／チェーン／支払いプロトコル／取引相手、時間制限）を持ちます。
• did:tenzro:machine:{uuid} — 自律型エージェントです。同じウォレットと A2A インターフェースを持ちますが、管理者はいません。プロトコル資金によるブートストラップエージェントには is_seed_agent を設定します。
• did:tenzro:institution:{lei}:{uuid} — 20文字の GLEIF Legal Entity Identifier（ISO 17442）に紐付けられた法人です。登録時には ISO 7064 Mod 97-10 のチェックディジット検証が行われます。vLEI ACDC クレデンシャル ID の紐付け、ISO 3166-1 alpha-2 国コード、KYB ティアを任意で設定できます。1つの法人が複数の機関アイデンティティ（部門／ファンド／子会社ごとに1つ）を持っても、LEI を再発行する必要はありません。

W3C DID ドキュメント。再帰的な信頼チェーン検証（循環検出、深さの上限設定、構成済みの信頼ルートへのアンカー設定）に対応した W3C Verifiable Credentials。クレデンシャルによる KYC／KYB ティアのアップグレード。連鎖的な失効。標準準拠の任意のクライアントが利用できる DIF 仕様の Universal Resolver（/1.0/identifiers/{did}）。長期利用する自律型マシンアイデンティティのための KERI Key Event Log（開始、ローテーション、事前ローテーションのコミットメントを伴うインタラクションイベント。SHA-256 の SAID プレフィックスは S）。オフチェーンサービス認証用の EIP-4361 形式のメッセージ Sign-In With Tenzro（SIWT）。

決済

暗号資産決済レール — TNZO またはステーブルコインでオンチェーン決済します：

• AP2（Agent Payments Protocol）：検証可能なエージェント決済に intent／cart／payment VDC を使用する Google／FIDO のプロトコルです。tenzro_validateMandatePair による委任ペア検証に対応しています
• MPP（Machine Payments Protocol）：Stripe と Tempo が共同開発した、セッションベースのストリーミング決済です
• x402（Coinbase）：EIP-3009 認証を使用するステートレスな HTTP 402 決済です。デフォルトのファシリテーターはセルフホスト型です。オペレーターがスキームの受付チェックを実行し、署名済み認証をリモートファシリテーターにルーティングするのではなく、自らの EVM 署名者を通じて決済します
• Tempo：EIP-155 トランザクション署名による、ステーブルコインの直接決済です
• アプリレジストリ＋開発者署名による決済：開発者は自身の DID でアプリを登録し、自らのみが管理する決済プロバイダーのアカウントに対して、承認済みの請求を決済します。開発者は各決済認証に署名し、ノードは請求をルーティングして結果を記録しますが、決済プロバイダーの秘密情報を保持することはありません。RPC は tenzro_registerApp / setAppStatus / getApp / listApps / settleAuthorized / getSettleAuthorizedOutcome、SDK は AppClient（Rust＋TypeScript）、CLI は tenzro app です
• 決済チャレンジと検証を自動化する HTTP ミドルウェア

カード決済レール — Visa／Mastercard が法定通貨を決済し、Tenzro が ID、委任、監査を提供します：

• Visa TAP（Trusted Agent Protocol）：エージェントは Tenzro が発行した委任エンベロープ（DID＋署名済み委任スコープ＋AP2 委任検証）を提示します。Visa がカード取引を承認して決済し、Tenzro がオンチェーン監査レシートを記録します
• Mastercard Agent Pay：同じ ID／委任／監査基盤を使用し、Mastercard がカード取引を決済します

これにより、1 つのエージェント ID で、カード決済レールの TAP 決済、x402 による USDC マイクロペイメント、Canton の DvP レッグを、1 つのタスク内で 1 つの委任エンベロープと 1 つの監査証跡を使用して組み合わせられます。これらの決済レールは、通常は相互運用できません。

セキュリティ

• 実際の TEE 統合：Intel TDX（/dev/tdx-guest）、AMD SEV-SNP（/dev/sev-guest）、AWS Nitro（/dev/nsm）、NVIDIA GPU CC（NRAS API）
• ベンダーのルート CA をピン留めした X.509 証明書チェーン検証
• HKDF 鍵導出を用いた AES-256-GCM エンクレーブ暗号化
• KoalaBear 上の Plonky3 STARK 証明（信頼されたセットアップ不要、耐量子健全性）と、O(1) の EVM 検証を可能にするオンチェーン ZkCommitmentRegistry
• Argon2id 鍵導出を用いた FROST-Ed25519（RFC 9591）2-of-3 閾値ウォレットと、必須の ML-DSA-65 耐量子署名の組み合わせ
• 証明可能に公平な乱数生成のための VRF（RFC 9381 ECVRF-EDWARDS25519-SHA512-TAI） — プリコンパイル 0x1007、NFT mintRandom（0x52517e21）

クロスチェーンブリッジ（本番用アダプター 16 種）

• LayerZero V2：EndpointV2 メッセージング、共有小数点を使用する OFT
• Stargate V2 Hydra：ネイティブ USDC／USDT／WETH の OFT ブリッジ（独立したアダプター。基盤では LayerZero V2 を使用）
• Chainlink CCIP：トークンプールを備えたルーターベースのクロスチェーンメッセージング
• Chainlink CCT：Cross-Chain Token v1.6 以降のセルフサービス型プールレジストリ（LockRelease + BurnMint）
• Wormhole：19 のガーディアンによる VAA アテステーション。Solana／Aptos／Sui を含む 30 以上のチェーンに対応
• Wormhole NTT：NttManager レジストリと、複数のトランシーバーに対応するチェーンカタログ（Wormhole／Axelar／LayerZero／カスタム）を備えたネイティブトークン転送
• deBridge DLN：インテントベースのクロスチェーンスワップ（公式 MCP プロキシ）
• LI.FI：ルート最適化機能を備えた 66 チェーンの集約
• Hyperlane V3：ソブリン型 Tenzro バリデーターセット ISM を使用したメッセージング（list_chains、quote_dispatch、dispatch）
• Axelar GMP：Cosmos／Move／Stellar／XRPL に対応
• Babylon：Bitcoin ステーキングのファイナリティプロバイダー + EOTS 委任
• IBC-Eureka：すべての Cosmos SDK チェーンを対象に、Tendermint ライトクライアントを SP1 plonk 証明に圧縮します。EVM 上の IBC_VERIFY プリコンパイル（0x1020）は、EVM 外のコミットメントレジストリを O(1) で検索します。
• BitVM2 / Clementine：楽観的チャレンジプロトコルを使用する、信頼を最小化した Bitcoin の双方向ペグ。ペグイン／ペグアウトのライフサイクルをオンチェーンで追跡し、デフォルトの決済期間は 7 日間です。
• Hyperbridge ISMP：Polkadot への HTTP 形式の POST／GET メッセージング。メッセージ受信時に、ミント制御とアセットごとのローリングウィンドウ流動性上限を適用します。
• NEAR Chain Signatures：NEAR MPC が Tenzro アカウントから Bitcoin、Ethereum、Solana、TON、Stellar、Sui、Aptos、Dogecoin 用の secp256k1／Ed25519 署名を生成します。
• Canton：エンタープライズ向け DAML 相互運用性

統合された BridgeRouter はリアルタイムの手数料見積もりを照会し、コスト、速度、信頼性に基づいてランク付けしたルートを返します。各アダプターは、受信メッセージの検証に失敗した場合、必ず処理を拒否します（Wormhole ではガーディアンのクォーラム、Hyperlane + Axelar ではしきい値バリデーターセット、Hyperbridge では ISMP 証明、Clementine では BitVM2 チャレンジプロトコルを使用）。アダプターごとの nonce トラッカーを永続化し、再起動後もリプレイを破棄します。プリコンパイル 0x1021 のグローバル供給量会計レジストリは、レール間を移動する Tenzro 発行トークンの唯一の整合性ログです。アセットとレールの組み合わせごとに単調増加するシーケンス（リプレイ防止）を適用し、Σ mints − Σ burns ≤ max_supply とバーン時のアンダーフローなしを保証します。

TNZO 建てブリッジ手数料 + Chainlink 対応手数料オラクル

• 単一トークンの UX：ユーザーは送信元チェーンで TNZO 建ての手数料を 1 回だけ支払い、送信先チェーンのネイティブ手数料はアダプターごとのスポンサーシッププールが立て替えます。
• 2 種類のオラクルバックエンド：GovernanceSetFeeOracle（手動レートテーブル。tenzro_setBridgeFeeRate による管理者トークンでのアクセス制御）と、ChainlinkFeedFeeOracle（30 秒のインメモリーキャッシュに加え、データの古さと無効な回答の拒否に対応し、AggregatorV3Interface.latestRoundData() を eth_call でリアルタイムに呼び出します）。
• アダプターごとのスポンサーシッププール：8 個の決定論的なボールトアドレス（"tenzro/bridge/sponsorship-vault" || adapter の SHA-256 の先頭 20 バイト）。tenzro_listBridgeSponsorshipPools で列挙できます。
• ERC-7683 エンベロープの統一：TenzroOrderData.bridge_fee_hint により、ユーザーが署名した単一の注文を、登録済みアダプターセット内の任意のブリッジで約定できます。ソルバーがアダプターを選択し、TNZO の上限額が送信先のネイティブ通貨でのコミットメントを制限します。
• オペレーター認証を必要とする上流コスト：Chainlink 読み取り用の Ethereum メインネット RPC クォータはオペレーターが支払います。メソッドは chainlink スコープの API キーでアクセスを制限します（Canton と同じモデル）。CF_BRIDGE_ANALYTICS でテナントごとの Compute Unit を割り当てます。GCRA レートリミッター（継続時は 10 req/sec、バースト時は 100）と -32005 リトライエンベロープに対応します。

トークン化とコンプライアンス

• ERC-7943 (uRWA)：実世界資産のコンプライアンス機能 — トークンのキルスイッチ（tenzro_urwaTriggerKillSwitch）、トークンの凍結（tenzro_urwaSetFrozenTokens）、強制送金（管理者トークンによるゲート制御）。
• IVMS101 v1.1.0：越境送金における KYC ペイロードのための、FATF トラベルルール準拠の標準エンベロープ。
• Secure-Mint：トークン化された RWA のための、トークンごとに 1:1 の準備金証明不変条件。
• TEE attested timestamps：サガのステップの期限と義務の有効期限には、30 秒のずれ許容範囲を備えた TEE 証明済みの wall_ms + monotonic_ns + tee_vendor エンベロープが付与されます。

エージェントの相互運用性

• ERC-8004：Ethereum 上のトラストレスなエージェントレジストリ — Tenzro のマシン DID を registerAgent/getAgent/submitFeedback/validationRequest/validationResponse インターフェースにミラーリングし、エコシステムをまたいだエージェントの評判を実現します。CLI では tenzro erc8004 と、標準の EIP-8004 短縮名エイリアス tenzro 8004 の両方を利用できます。
• AP2：インテント／カート／支払いの VDC 委任状、セッションのライフサイクル、委任状ペアの検証を備えたエージェント決済プロトコル
• AAP（Agent Access Protocol）：エージェントが発行するベアラートークンのための OAuth 2.1 + DPoP + RAR レイヤリング。CLI では tenzro auth とそのエイリアス tenzro aap の両方を利用でき、どちらの名前でも同じ tenzro_*Token* およびウォレットリンク RPC が呼び出されます。

マルチパーティワークフロー（VM 非依存。Canton ミラーリングは任意）

ワークフローランタイムは独立したステートマシンです。VM と並行して（VM 内ではなく）動作し、独自の型付きライフサイクル、ステップごとの execute / verify / compensate ハンドラー、特権 VM トランザクションセレクターによるオンチェーンレシート、手数料ルート、キルスイッチ、プライバシードメインを備えています。Canton ミラーリングは任意のプロジェクションです — ワークフローで canton_mirror: Some(...) を宣言すると、ワークフローディスパッチャーは各ステップについて、同じ場所に配置された Canton participant を介して Tenzro.Workflow.Receipt 行を書き込みます。canton_mirror: None を指定したワークフローは Canton とやり取りせずに実行されます。EVM コントラクトは標準のイベントサーフェスを通じてワークフローイベントを購読します。SVM プログラムは統合トークンレジストリのイベントログを通じてレシートを参照します。

• ライフサイクル：型付きステートマシン（Draft → Active → AwaitingSignatures → Executing → Completed、終端状態は Cancelled / Disputed / Failed / Suspended）を備え、すべての状態変更に特権 VM セレクター 0x01000040–0x0100004B を使用します。
• レシート：遷移ごとに WorkflowReceipt が生成され、ワークフローごとのハッシュチェーンに連結されます。wf_receipt:<id> に永続化され、任意で同じ場所に配置された Canton participant を介して Tenzro.Workflow.Receipt Daml テンプレートにミラーリングされます。
• プライバシードメイン：名前付き ACL で TDIP DID を指定し、AES-256-GCM でシールされたペイロードへのアクセスを制御します。監査担当者には読み取りアクセスが提供され、ガバナンスに基づく凍結も可能です。
• 手数料ルート：読み取り専用プレビュー用の tenzro_computeFeeRoutePayouts を備えた、ベーシスポイント単位の受取人テーブルです。実際の決済はコンセンサス仲介型エスクロー機構を通じて実行されます。
• キルスイッチ：KillSwitchSuspend / KillSwitchCancel セレクターにより、開始者に明確な緊急停止経路を提供します。これにより、自律エージェントが自ら開始した応答不能なマルチパーティフローから抜け出せなくなることを防ぎます。
• インターフェース：JSON-RPC（tenzro_*）、MCP（ポート 3001）、A2A（Tenzro Agent Card の workflow スキル）を通じた読み取り専用アクセスを提供します。/metrics では運用メトリクスのスナップショットを確認でき、Grafana ダッシュボード（UID tenzro-workflow）も同梱されています。
• リファレンステンプレート：crates/tenzro-workflow/reference_workflows/ に 5 つの実例（自律調達、自律トレジャリー、DvP 決済、環境 MRV、サプライチェーン DPP）があり、それぞれに任意の Canton DAML プロジェクションを記述した **_daml_map.json` が対応しています。

コンプライアンスと開示（EU AI Act 第50条）

• §50(1) チャットボットの開示：すべての CLI／MCP／A2A の AI テキスト応答には、先頭に [AI] が付加されます。唯一の信頼できる情報源は tenzro_node::eu_ai_disclosure です。
• §50(2) 合成コンテンツのマーカー：すべての推論出力には、SHA-256 コンテンツハッシュをキーとする C2PA 形式の ContentProvenanceManifest が付与されます。バリデーターは Ed25519 ブロック署名キーでマニフェストに署名します。RPC tenzro_getContentProvenance と CLI tenzro provenance get <content_hash> で、キャッシュされたマニフェストを取得できます。
• §50(4) ディープフェイクのアサーションタグ：実在する対象を模倣する出力には、ai-generated の代わりに deepfake アサーションが使用されます。
• 承認フロー：対象範囲外のエージェント操作は、コントローラーの確認のため保留されます。tenzro approval list/get で確認し、tenzro approval decide で決定します。
• チャネルの異議申し立て：永続的なライフサイクル記録は、tenzro dispute status と tenzro dispute list-by-channel で読み取れます。
• プロバイダーの評判：tenzro reputation get <provider> で、推論ルーターが使用する永続的なスコア（0～1000、成功で +1／失敗で −5）を取得します。

ノード内のデータの保存場所

Tenzro がマシンに書き込むデータはすべて、1つのルート配下に保存されます。これは $TENZRO_HOME、未設定の場合は ~/.tenzro です。モデルの重み、HuggingFace キャッシュ、データセットのシャードは、マシン上のすべての Tenzro プロセスで共有されます。コンテンツアドレス方式で管理され、書き込み後は読み取り専用となるため、2つのノードが同じ重みのコピーを別々に保持することはありません。チェーンの状態は instances/<name>/ 配下のインスタンスごとに保存されます。RocksDB は共有できないため、同じディレクトリを開こうとした2つ目のプロセスは、ロックファイルによって失敗します。

$TENZRO_HOME
├── models/          shared — GGUF weights, ONNX bundles
├── hf/              shared — HuggingFace cache (exported to child processes)
├── trainer-cache/   shared — dataset shards, keyed by digest
└── instances/
    └── default/     RocksDB, keys, wallets, snapshots, iroh blobs

--data-dir は引き続きインスタンスごとのディレクトリを上書きし、models_dir は共有ストアを上書きします。大容量データを別のボリュームに置くオペレーター向けです。コンテナーイメージでは TENZRO_HOME=/data/tenzro が設定されるため、モデルストアは一時レイヤーではなく、マウントされたボリューム上に保存されます。

認可モデル

異なる問いに答える、次の3つのレイヤーがあります。

• Admission（admission.rs） — オペレーターが任意に設定するサービスキーによって、サービスの各機能へのアクセスを制御します。コンセンサスやゴシップにはこの制御方式がないため、ゲートを設定したノードが検証を停止することは構造上できません。サービスキーは、このマシンの生のリソース（制限付きシェル、ストレージ、メモリ、コンピューティング）を利用するためのレンタル認証情報であり、利用可能な機能と有効期限を含む ServiceKeyGrant を持ち、発行対象の AccessLease に紐付けられます。これはノードが何を提供するかを示すものではありません。モデルの提供可否は、このゲートではなくモデル自身の公開範囲によって決まります。 network の公開範囲で公開されたモデルは、ゲートが設定されたノード上でも、支払いだけで利用できます。ゴシップ経由でオファーを見つけたピアには、キーを取得する手段がないためです。詳細は docs/ACCESS.md を参照してください。
• 分類（rpc_gates.rs） — ディスパッチされる各メソッドは、ADMIN_METHODS（109）または OPEN_METHODS（823）のいずれか1つに必ず含まれます。どちらにも含まれないメソッドは、ハンドラーが実行される前に拒否されます。テストではディスパッチャー自身のソースを読み取るため、ゲートを決めずに RPC を追加すると、監査での指摘ではなくビルド失敗になります。
• 所有権 — テナントのリソースを操作するメソッドには、そのリソースの所有者による署名付き DID エンベロープが必要です。このエンベロープはメソッド名と呼び出しパラメーターに紐付けられます。オペレーターの管理トークンは、マシンを実行する人を認証するものです。共有ノードのホストがテナントのリソースを変更できてしまうため、ノードを_利用する_人に属するリソースのゲートとしては適切ではありません。

submitBlock、offerSnapshot、applySnapshotChunk は JSON-RPC の機能として公開されていません。これらはユーザー向けポートから到達できるピア間通信でした。submitBlock は呼び出し元が指定したブロックを確定済みの経路に投入していましたが、契約上、その経路に到達するブロックはすでにコンセンサスを経ているため、何も検証されません。ブロックはピア認証済みのゴシップおよびブロック同期を通じて届きます。状態同期の受信側はプロセス内で駆動されます。読み取り側（listSnapshots、getSnapshotManifest、getSnapshotChunk）は、同期中のノードが提供側のノードを呼び出すものであり、変更されていません。

エコシステム

コンポーネント	リポジトリ	説明
MCP Server（Python）	tenzro/tenzro-mcp-server	360 個のツール、FastMCP 3.x
A2A Server（Python）	tenzro/tenzro-a2a-server	75 個のスキル、FastAPI
TenzroClaw（Python）	tenzro/TenzroClaw	685 個のコマンド、OpenClaw スキル
Rust SDK	tenzro/tenzro-sdk-rust	85 個のモジュール
TypeScript SDK	tenzro/tenzro-sdk-typescript	92 個のモジュール
ブラウザー拡張プロバイダー	sdk/tenzro-inject	dApp 向けの window.tenzro — EIP-1193 / EIP-6963 / Wallet Standard / CAIP-25
Homebrew	tenzro/homebrew-tap	brew install tenzro
クックブック	tenzro/tenzro-cookbook	実行可能なサンプル 34 件
デスクトップアプリ	tenzro/tenzro-desktop	Tauri + React

ライブテストネット

サービス	URL
JSON-RPC	https://rpc.tenzro.xyz
Web API	https://api.tenzro.xyz
MCP Server	https://mcp.tenzro.xyz/mcp
A2A Server	https://a2a.tenzro.xyz
フォーセット	https://api.tenzro.xyz/faucet
Solana MCP	https://solana-mcp.tenzro.xyz/mcp
Ethereum MCP	https://ethereum-mcp.tenzro.xyz/mcp
Canton MCP	https://canton-mcp.tenzro.xyz/mcp
LayerZero MCP	https://layerzero-mcp.tenzro.xyz/mcp
Chainlink MCP	https://chainlink-mcp.tenzro.xyz/mcp
LI.FI MCP	https://lifi-mcp.tenzro.xyz/mcp
ドキュメント	https://tenzro.com/docs

インフラストラクチャ：tenzro.xyz の公開エンドポイントは、ネットワーク上で最初の参照 RPC プロバイダーである Tenzro Labs が運営しています。RPC プロバイダーの役割は公開されており、バリデーター保証金の要件を満たすオペレーターであれば誰でも独自のエンドポイントを登録し、同じプロトコルインターフェースを提供できます。エッジでの TLS は PQ ハイブリッド X25519MLKEM768 です。このリポジトリは参照実装であり、誰でもノードを実行して参加できます。

ジェネシス：TNZO の総供給量は 1,000,000,000 です。フォーセット：1 回のリクエストにつき最大 1,010 TNZO、クールダウンは 24 時間です。上限は、モデルプロバイダーの保証金 1,000 TNZO に、その投稿に必要なガス代分の余裕を加えた額です。保証金と同額の助成金では、保証金を投稿するトランザクションの費用を賄えません。

開発

# Build all crates
cargo build

# Run all tests
cargo test --workspace

# Run clippy
cargo clippy --workspace

# Run node locally
cargo run --bin tenzro-node -- --roles validator --data-dir ./data

# Run CLI
cargo run --bin tenzro -- --help

必要要件

• Rust 1.85 以降（rust-toolchain.toml を参照）
• C/C++ コンパイラー（RocksDB、libp2p 用）
• cmake（llama-cpp-sys-2 用）
• protoc — Protocol Buffers コンパイラー 3.12 以降（agent-memory のベクトル層を通じて間接的に取り込まれる lance-encoding で必要です）
• pkg-config、libssl-dev（Linux）

protoc をインストールします。

# macOS
brew install protobuf

# Debian / Ubuntu
sudo apt-get install -y protobuf-compiler

# Fedora / RHEL
sudo dnf install -y protobuf-compiler

# Arch
sudo pacman -S --needed protobuf

# Rust-only (no system package manager)
cargo install protoc-bin-vendored-cli

protoc --version で確認します（libprotoc 3.12 以降と表示される必要があります）。プラットフォームごとのツールチェーンの全手順については、docs/GUIDE.md を参照してください。

Docker

# Build image
docker build -t tenzro-node .

# Run node
docker run -p 8545:8545 -p 8080:8080 -p 3001:3001 -p 3002:3002 \
  -v tenzro-data:/data/tenzro \
  tenzro-node --roles validator --data-dir /data/tenzro

デプロイ

標準的なデプロイ方法は、systemd を搭載したホスト上での Docker です。キー管理、ネットワーク、アップグレード手順を網羅した、インフラに依存しないオペレーター向けガイドについては、deploy/validator-deployment.md を参照してください。

Proto 定義

proto/tenzro/v1/ の下にある 13 個の proto3 ファイルで、120 種類以上のメッセージ型を定義しています。これらは API ドキュメントとして機能します。Rust の型は柔軟性を確保するため、手動で実装されています。

ドキュメント

ドキュメント	目的
docs/WHITEPAPER.md	Tenzro Network のホワイトペーパー — ビジョン、アーキテクチャ、エージェント経済、決済レイヤー
docs/SPECIFICATION.md	プロトコル仕様 — アーキテクチャ、コンセンサス、マルチVM実行、ID、決済、決済処理、エージェント、トレーニング、および具体的な Rust 実装
docs/ECONOMICS.md	正式な基準：誰が支払い、誰が受け取り、金額はいくらか。ノードの経済モード、収益配分、アクセス階層、決済処理、来歴、マシンID
docs/TOKENOMICS.md	TNZO トークンの経済設計：供給量、手数料モデル、ステーキング、報酬（テストネットフェーズ）
docs/TDIP.md	Tenzro Decentralized Identity Protocol — 人間、委任されたエージェント、自律エージェント、機関にまたがる W3C DID に基づく ID；マシンアンカー、デバイスバインディングとハードウェアに紐付いたパスキー、セッション、ウォレットのセカンドデバイスルール、マシン所有権の移転
docs/AI.md	Tenzro AI — 分散型推論（単一レプリカ＋シャーディング MoE＋MTP＋マルチモーダル）、Cortex 推論、機密推論、Tenzro Train（データ並列、分離型の外部同期）トレーニング、Tenzro Media Gen（拡散モデルによる画像・動画生成、エキスパート分割レンダリング）
docs/COMPUTE.md	Tenzro Compute — レンタル可能なコンピューティング容量：エポック単位の予約、可用性証明ゲート、ストリーミングエスクロー、固定またはネットワーク動的な料金設定、ストレージとの共有担保
docs/STORAGE.md	Tenzro Storage — 分散型コンテンツアドレス指定ストレージ：バイトエポック課金、取得可能性証明、冗長性、コンピューティングと共有するステーク
docs/DATABASE.md	Tenzro Database — マネージドデータベースのプロトコルレイヤー：エンジンカタログ（PostgreSQL、Qdrant、Milvus、Valkey、Dgraph、Lance、Tantivy）、ローカル／LAN クラスター／ネットワーク階層への配置、アクセス ポリシー＋機密シール
docs/HOSTING.md	Tenzro Hosting — Tenzro ノード上の静的サイト、関数、マシン：コンテンツアドレス指定による配信、wasi:http サンドボックス、Firecracker microVM、入札／リースによる配置、自動 TLS を備えたオペレーター設定のエッジ
docs/ORCHESTRATION.md	インテントオーケストレーション — 決定論的なガードレールを備えた LLM プランナーの背後で、モデル、スキル、ツール、エージェントを組み合わせる
docs/NETWORK.md	Tenzro Network — 分散型ネットワーキング：libp2p コントロールプレーン（gossipsub トピック、NAT トラバーサル、バリデーター専用トピック認証、リクエスト／レスポンスプロトコル）＋iroh QUIC データプレーン（DA、モデル重み、勾配、シール済みシャード、エージェントメモリ、A2A＋MCP ALPN）
docs/GUIDE.md	オペレーターおよび開発者向けガイド：ビルド、実行、デプロイ、トラブルシューティング
docs/did-method-tenzro.md	did:tenzro DID メソッド仕様（W3C 登録申請）
deploy/validator-deployment.md	インフラに依存しないバリデーターおよびノードオペレーター向けガイド
docs/security/	セキュリティモデル、耐量子計画、監査メモ

貢献

ガイドラインについては、CONTRIBUTING.mdをご覧ください。すべての貢献には、Apache-2.0ライセンスに基づくサインオフが必要です。

ライセンス

Apache License 2.0です。詳しくはLICENSEをご覧ください。

Copyright 2024-2026 Tenzro Foundation.