Auth surfaces.

Every public surface on a Tenzro node falls into one of two buckets. The decentralization invariant is that the first bucket is identical on every validator; the second is the operator’s own service offering.

Network surfaces— open to any caller, authenticated by the caller’s own signature over their own request. No operator-issued token. Same UX on every validator.

Operator-hosted services— the node operator chose to host a service (e.g. wallet custody, model serving). Authentication is to that node, with credentials the operator issued. Optional — a minimal validator skips them entirely.

Caller signs the request with their own DID-bound key. Any validator looks the DID up in the chain-replicated identity registry and verifies the signature. There is no per-node enrollment, no bearer token, no operator gating.

rpc.tenzro.xyz      JSON-RPC 2.0 (port 8545)
a2a.tenzro.xyz      A2A protocol (port 3002)
mcp.tenzro.xyz/mcp  MCP server (port 3001)
api.tenzro.xyz      Web verification + faucet + status (port 8080)

Mutation methods on RPC and A2A use caller-bound signatures. The caller produces an Ed25519 or Secp256k1 signature over a domain-separated preimage, attaches their DID and public key, and the receiving node verifies. A2A mutation methods carry a five-key tenzro.a2a.envelope.* metadata block per the DID envelope contract.

Read methods (block queries, balance lookups, model catalog, etc.) require no authentication at all.

A node operator can choose to host wallet custody, model serving, TEE leasing, or other services on top of their validator. These have their own authentication scoped to the operator — not to the network — and do not participate in consensus.

/wallet/frost/*        FROST (RFC 9591) round coordinator
/wallet/mldsa/*        ML-DSA-65 signing surface
/wallet/share/*        Passkey share-unwrap
/oauth/token           OAuth 2.1 token issuance
/chat                  AI inference (HTTP 402 when paid)

FROST and share-unwrap endpoints authenticate the wallet that owns the share on this nodevia DPoP JWTs (RFC 9449). A wallet that pairs with validator-0 cannot use validator-7’s FROST endpoint — validator-7 does not hold the share. The JWT is not gatekeeping network participation; it is protecting custody.

Skip these endpoints entirely if you want self-custody: generate your own keypair, sign your own transactions, submit via the open RPC surface. The OAuth and FROST machinery never activates on that path.

Tenzro’s positioning is that RPC node operators get the architecture to manage resources and access. Unlike Ethereum (where every operator has to build their own gateway infrastructure on top of geth/reth) or Canton (where validators can’t expose public RPCs at all), a Tenzro node comes with built-in API-key issuance, OAuth/DPoP gating, scope-based access control, per-tenant analytics, and upstream-credential mediation as part of the operator surface. This applies uniformly to Canton, EVM, SVM, models, TEE, and any other upstream the operator wants to gate.

Some Tenzro RPC methods proxy to an upstream that the operator— not the caller — holds credentials for. The canonical case is Canton: a node operator holds the upstream credentials that authorize outbound calls to its Canton JSON Ledger API endpoint; callers never touch them. Canton can’t have public RPCs (its validator architecture requires authenticated access), so Tenzro’s mediation surface is what makes Canton accessible to external callers in a controlled way. The same pattern extends to EVM contracts and SVM programs that operators want to gate (e.g. private model inference, premium TEE attestation, rate-limited bridge submissions).

Every operator that hosts mediated upstreams runs their ownissuance and revocation surface for API keys against that one node. There is no global Tenzro Labs key authority — Tenzro Labs is one operator instance among many. The caller presents a tnz_<base64url> token as the X-Tenzro-Api-Key header; the node hashes it, looks it up, checks scope, and transparently handles the upstream call.

curl -X POST https://rpc.tenzro.xyz \
  -H "content-type: application/json" \
  -H "X-Tenzro-Api-Key: tnz_..." \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_listCantonDomains","params":{}}'

Keys carry one of three classes — Subject (bound to a Tenzro DID, holder can self-revoke), OperatorInternal (operator-only automation, no self-service revoke), OperatorProtected (long-lived operator infra, not revocable over RPC at all). Methods matched by tenzro_*Canton* or tenzro_*Daml* require scope canton; missing or wrong-scope keys collapse to JSON-RPC error -32004. Full lifecycle reference at API keys.

A node serves each Canton network independently, and a key is authorized for a subset of them. Name the target with the canton_network JSON-RPC param, the X-Canton-Network header on the Canton MCP server (its gate sits above the MCP envelope and cannot read tool arguments), or --canton-networkon the CLI. Resolution order is the explicit selector, then the key’s sole authorized network, then the node’s configured default. A key authorizing exactly one network needs no selector; a key authorizing more and given none returns -32004 naming the authorized set.

Each key carries a tier bounding its budget over a sliding 60-second window: free at 60 requests/min with writes refused, standard at 600, priority at 6,000. Over-budget returns -32005 with retry_after_ms, requests_per_minute, and tier.

Keys gate operator-brokered resources only. Publishing to the marketplace registry — agents, skills, workflows, MCP servers — is permissionless, priced by the provider in TNZO or offered free, and needs no operator approval.

Operator-mediated methods split across two independent gates. X-Tenzro-Api-Key presents a caller-held tnz_... token and unlocks scope-gated upstreams (Canton today). X-Tenzro-Admin-Tokenpresents the operator’s admin token and unlocks issuance + admin lifecycle: tenzro_createApiKey, tenzro_listApiKeys, tenzro_revokeApiKey, plus tenzro_gracefulExit, debug methods, secrets queries.

Subject-class key holders get their own admin-free revoke surface: tenzro_listMyApiKeys and tenzro_revokeMyApiKeyare gated by the caller’s own tnz_...and return only keys whose subject matches the calling key’s subject. An ownership probe against a key the caller does not hold collapses to -32004— no cross-subject discovery surface.

The admin token never leaves the node it was issued on and is not a network credential. The two headers are independent and may both be present on a single request.

Identity, credential, and token issuance carry their own gates and revocation paths so that a compromised or expired credential can be withdrawn network-wide.

Revocation broadcast. tenzro_revokeIdentity (admin-token-gated) revokes a DID in the local registry and broadcasts the revocation to the network, where receiving nodes apply it to their own replicated registry. Credential and JWT revocation follow the same shape via tenzro_revokeJwt. Revocations are persisted, so a node that was offline during the broadcast still converges on restart.

Trusted issuers.Credential, service, and claim issuance RPCs verify the issuer against the registry’s trusted-issuer set. tenzro_addTrustedIssuer is admin-token-gated; an issuance from an unlisted issuer is refused rather than silently accepted.

DPoP and replay. Token exchange is bound to a DPoP proof (RFC 9449) so a token cannot be replayed from another key. The replay cache is persisted rather than in-memory, and refresh-token revocation is wired through the same lifecycle so a revoked session cannot be silently refreshed.

1.Any developer can call any validator’s RPC / A2A / MCP from anywhere, signing with their own keys.

2.A user’s DID and signature work identically on every validator — no per-node enrollment.

3. Agent-to-agent messages and chain transactions flow through the open RPC and A2A surfaces, open by signature. Operator-mediated upstreams (Canton, paid inference) are scoped to the operator that runs them; any other operator can stand up the same mediation independently under their own credentials.

4. Every validator must serve the open surfaces. No validator is required to host wallet custody, mediated upstreams, or any other operator-hosted service.