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.network      JSON-RPC 2.0 (port 8545)
a2a.tenzro.network      A2A protocol (port 3002)
mcp.tenzro.network/mcp  MCP server (port 3001)
api.tenzro.network      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 ships with built-in API-key issuance, OAuth/DPoP gating, scope-based access control, per-tenant analytics, and upstream-credential mediation as a first-class 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.network \
  -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.

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.

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.