Resources.

Six first-class registries hold the discoverable resources on a Tenzro node. Each registry has its own per-class RPC surface (registration, listing, search, invocation), and all six are also reachable through a single unified discovery surface described in section 02.

tenzro_listResources collapses all six registries into one query. An agent specifies which classes to search, which capability tags to require, an optional TNZO price ceiling, and gets back a uniform list of ResourceDescriptor rows.

{
  "jsonrpc": "2.0",
  "method": "tenzro_listResources",
  "params": {
    "classes": ["tool", "knowledge", "model"],
    "capability_tags": ["prices", "finance"],
    "max_tnzo_price": "10000000000000000",
    "query": "us equities",
    "limit": 50
  },
  "id": 1
}

To invoke any resource by id, call tenzro_useResource. The dispatcher auto-detects which registry holds the resource and routes to the per-class handler. Pass class explicitly to skip the auto-detect.

{
  "jsonrpc": "2.0",
  "method": "tenzro_useResource",
  "params": {
    "resource_id": "k-pricefeed-001",
    "params": { "symbol": "SOL/USD" },
    "payer_wallet": "0x..."
  },
  "id": 1
}

Operators run custom and third-party MCPs — payments, identity-and-KYC, devtools, docs, custody, data feeds, and operator-built ones — on their Tenzro node without forking the codebase. Three transport modes are supported: mcp for remote Streamable HTTP, mcp-stdio for local subprocesses, and mcp-sse for legacy SSE.

Operator upstream credentials (payment-processor secrets, model-provider API keys, premium data-feed subscriptions) live in a sealed credential vault on the node: AES-256-GCM at rest, keyed by per-secret HKDF-derived material rooted at either an operator-supplied master secret or an auto-derived node-identity IKM. Tenants never see operator credentials — the plaintext is read from the vault at invocation time, injected into the outbound MCP request, and zeroized from memory after the call completes.

Operator stores a credential via tenzro_storeMcpSecret (admin-token-gated):

{
  "jsonrpc": "2.0",
  "method": "tenzro_storeMcpSecret",
  "params": {
    "sealed_secret_ref": "stripe_api_key_v1",
    "plaintext": "sk_live_..."
  },
  "id": 1
}

Operator then registers an MCP that references the sealed ref. For a stdio MCP that ships as an npm package:

{
  "jsonrpc": "2.0",
  "method": "tenzro_registerTool",
  "params": {
    "name": "stripe-mcp",
    "version": "1.0.0",
    "tool_type": "mcp-stdio",
    "endpoint": "stripe-mcp-local",
    "description": "Stripe MCP — payment intents, customers, charges",
    "category": "payments",
    "creator_wallet": "0x...",
    "price_per_call": "2000000000000000",
    "spawn_spec": {
      "command": "npx",
      "args": ["-y", "@stripe/mcp", "--tools=all"],
      "persistent": true
    },
    "upstream_auth": {
      "kind": "env_var",
      "env_var_name": "STRIPE_API_KEY",
      "sealed_secret_ref": "stripe_api_key_v1"
    }
  },
  "id": 1
}

Tenants invoke it via the standard tenzro_useTool with their API key. The plugin host spawns the subprocess on first use, injects the operator's sealed credential as an environment variable, dispatches the call, settles the TNZO payment, and returns the MCP response.

Tenant API keys carry per-resource-class allow-lists. When a key has a non-empty allow-list for a class, only resource ids in that list are invokable. The full set of fields on tenzro_createApiKey:

• allowed_tools — tool / MCP resource_ids
• allowed_skills — skill_ids
• allowed_knowledge — knowledge resource_ids
• allowed_workflow_templates — workflow template_ids
• allowed_agent_templates — agent template_ids
• allowed_models — model_ids
• max_per_resource_tnzo — { "<resource_id>": "<atto_tnzo>" } per-resource cap

All optional. Empty fields preserve legacy unrestricted access. See API keys for the full issuance reference.

tenzro_spawnChildAgent atomically registers a new machine identity with controller_did set to the parent, auto-provisions an MPC wallet via WalletBinder, transfers the requested TNZO budget from parent_walletto the child's wallet, and binds a runtime SpendingPolicy on AgentRuntime.

{
  "jsonrpc": "2.0",
  "method": "tenzro_spawnChildAgent",
  "params": {
    "parent_did": "did:tenzro:machine:parent-abc",
    "display_name": "trading-subagent-7",
    "tnzo_budget": "100000000000000000",
    "parent_wallet": "0x...",
    "valid_until": 1750000000,
    "max_per_transaction": "10000000000000000",
    "max_daily_spend": "50000000000000000",
    "key_type": "ed25519"
  },
  "id": 1
}

Failure semantics: identity registration is the load-bearing step. If it fails, no funds move. If funding fails after registration, the identity remains (the operator can fund later) and the error surfaces explicitly. Spending policy is best-effort.

Every paid resource invocation runs the same commission split: 5% to network treasury, 95% to the operator's creator_wallet. The operator's upstream costs (payment-processor fees, model-provider plans, premium data-feed subscriptions) are off-protocol — the operator converts TNZO revenue to fiat to pay them. The protocol charges only for network use.

See Tokenomics for the full TNZO economic model.