RPC node operators.
- STATUS
- Phase 0 (Tenzro Labs only)
- CRATE
- tenzro-node
- STABILITY
- Bootstrap
- REFERENCE
- Canton + Splice + Pocket
The operator model
A Tenzro RPC node is more than an Ethereum-style RPC gateway. It is the per-operator authority that:
- Issues and revokes per-tenant API keys (
tnz_<base64url>) with scope-based gates (Canton, EVM, SVM, Inference, TEE, Bridge). - Mediates upstream credentials the caller cannot hold — Canton JWTs, model-router contract calls, premium TEE attestation, rate-limited bridge submissions.
- Tracks per-tenant call counters, auto-provisions Canton parties + users + grants at issuance, and tears them down at revocation.
- Optionally runs Stage 2 per-tenant IDPs — minting a per-tenant upstream OAuth client per key so each tenant has their own auditable Canton principal.
Every operator runs their own issuance + revocation surface against their one node. There is no global Tenzro Labs key authority. Tenzro Labs is one operator instance among many — today, the only one; tomorrow, one of dozens.
Phase 0 — Tenzro Labs only (now)
During testnet bootstrap, Tenzro Labs is the only RPC node operator. The fleet at rpc.tenzro.network is 10 tri-continental GCE validators we run; the API keys we issue (Manexus, Furcate, Tenzro Labs internal, etc.) are minted by us against our admin token.
There is no external onboarding in Phase 0. The protocol surface for operator registration exists in the codebase as feature-flagged scaffolding, but the network only recognises Tenzro Labs’s operator identity.
Phase 1 — Permissioned operator onboarding (testnet → mainnet)
As the ecosystem stabilises, third-party RPC operators can register. Three hard prerequisites:
- Canton mainnet validator. The operator MUST be a Canton mainnet validator. Without their own validator, they have no upstream JWT — and without that JWT they cannot mediate any Canton call. This is non-negotiable: it’s a structural property of Canton’s gated-validator architecture, not a Tenzro-imposed rule. The same architecture extends to anythingthe operator wants to gate on EVM / SVM / model surfaces — if they want to expose mainnet Canton calls, paid model inference, or attested TEE evidence, they need credentials for those upstreams.
- Hardware floor.Reference build: 32 vCPU / 64 GB RAM / 1 TB NVMe SSD / 1 Gbps symmetric. This is the baseline for serving a single-region public RPC at testnet load; tri-continental fleets (like Tenzro Labs’s) require this per region. Hardware floor is a soft requirement at Phase 1 (encouraged + checked at registration via a self-reported probe), hardening to enforced at Phase 2.
- TNZO stake bond. RPC operators are Tier 3 validators per the canonical three-tier model — they bond at least 100,000 TNZO (10× the Tier 2 staked validator minimum, reflecting the larger trust surface RPC providers carry: tenant API keys, upstream credentials, cross-chain mint routing, per-tenant billing). The Tier 3 bond includes the Tier 2 minimum — effective bond is 100k total, not 110k. The bond is held in escrow; equivocation, censorship, frontrunning, mishandled tenant secrets, billing fraud, and persistent SLA failures are slashed against it. Stake bond is released after a graceful exit + 7-day unbonding period.
Registration happens via an on-chain governance proposal that the operator signs with their TDIP machine identity. The proposal carries: their Canton validator party id, the public address of their Tenzro node, their advertised SLO targets, and a stake-lock signature.
Stability SLOs and slashing
Operators commit to per-region SLO bands on registration. Default Phase-1 targets:
- Availability: 99.9% monthly uptime (≤ 43 minutes of unplanned downtime per 30-day window).
- Latency: p95 ≤ 250ms intra-region, p95 ≤ 800ms cross-region for non-canton scopes. Canton-mediated scopes get +500ms upstream allowance (Canton 3.5 JSON Ledger API roundtrip).
- Block-height freshness: within 5 blocks of the current chain tip; an operator running > 50 blocks behind for a 5-minute window triggers automatic deregistration.
- Canton freshness: within 60 seconds of the participant’s last
activeAtOffset.
Slashing is graduated. The first 0.1% slash for a missed SLO month is a warning; repeat in the same quarter doubles. Three consecutive monthly misses or a single missed-freshness event > 30 minutes triggers operator deregistration (full bond returned after the 7-day unbonding period; operator removed from the public registry).
Slashing is dispatched via on-chain governance with prior evidence published; an operator may appeal via the same governance channel before slash execution.
Phase 2 — Permissionless onboarding (mature mainnet)
Once mainnet matures, operator registration becomes permissionless: any actor who meets the Canton-validator prerequisite, posts the stake bond, and passes the hardware probe is automatically registered. No governance vote required. Slashing remains stake-weighted.
Operator reputation is tracked on-chain via the same per-validator LeaderReputationprimitive Tenzro uses for HotStuff-2 proposer selection — downtime, failed Canton roundtrips, and slashing events all decay the operator’s reputation score, which drives both their relay-session allocation (in the Pocket-style routing layer) and their bond-recovery rate after slashing.
Why the Canton-validator prerequisite is not optional
Ethereum-style RPCs ride on top of geth/reth and can be operated by anyone with disk space. Tenzro RPCs ride on top of Canton, which does not permit public RPCs at the participant layer — access requires authenticated JWTs against the operator’s mainnet validator identity. A would-be Tenzro RPC operator without a Canton mainnet validator can serve the chain’s EVM/SVM/inference surfaces but cannot mediate Canton.
Since Canton is the single most-cited reason institutions deploy on Tenzro (it’s where the regulated tokenized-asset surface — tokenized treasuries, bank deposit tokens, and CIP-56 settlement — converges), an RPC operator without Canton has limited commercial appeal. The Phase-1 hard requirement reflects this market reality: operators who can mediate Canton are the operators users want; we make that the entry bar.
Canton mainnet validators are the natural Phase-1 candidates for Tenzro RPC operation — the same entity already runs the upstream participant and already holds the credentials needed to mediate. Adding the Tenzro RPC role to an existing Canton mainnet validator deployment is incremental, not greenfield.
Comparison: how Tenzro compares to other RPC models
- Alchemy / Infura.Custodial. Single corporate operator. 99.99% SLA via paid plans. No on-chain stake. No native multi-tenant key issuance — tenants are accounts in a private database, not protocol-recognised principals.
- Pocket Network. Stake-bonded permissionless (15,000 POKT min, ~$200). Session-based routing. QoS p95 SLO bands. No Canton, no mediated-upstream model.
- Canton mainnet validators.Permissioned. Operator runs a participant on the Canton mainnet synchronizer. Hardware floor + performance-based incentives. Canton-native. No external RPC surface on its own — mediating Canton to external callers requires building a gateway in front of the participant.
- Tenzro RPC operators.Tier 3 validators in the canonical three-tier model. Open entry from day one: any operator that meets the Canton-validator prerequisite + bonds 100,000 TNZO can register as a Tier 3 RPC provider. Native multi-tenant API key issuance with scope gates + per-tenant Canton auto-provisioning. SLO-bonded, slash-able. Combines Pocket’s stake-weighted operator model with Canton’s mainnet-validator prerequisite and Alchemy’s enterprise-grade SLO targets — the gateway-in-front-of-participant pattern is what Tenzro RPC nodes are.