Operator Registry

An operator registry is the authoritative list a network consults before letting any participant do real work on it: the difference between "an anonymous GPU on the internet" and "a vetted operator this network has formally admitted." It's a deliberate design choice, not a default: fully open, permissionless networks let anyone join with no vetting at all, which maximizes participation but means the network can never be sure who it's actually trusting with sensitive work. A registry inverts that: someone, governance, an admissions process, a multisig, decides who gets in, and only admitted identities can ever receive live traffic.

The tradeoff is real in both directions. A permissionless pool scales faster and needs no gatekeeper, but leaves a network with no lever to pull against a bad actor beyond after-the-fact detection. A permissioned registry adds friction and a central admission decision, but means every participant is a known, accountable entity before it ever touches anything, which matters enormously when the work involves sensitive data like a face image submitted for identity verification.

Where it comes from

Gated, allow-list-based membership isn't a single named invention, it's a general and widely used pattern across permissioned distributed systems. What's specific to Solidus's situation is the reasoning for choosing it: Solidus's own compute-network design documentation cites 2026 data showing permissionless commodity GPU marketplaces (Akash, io.net) contracting in provider count and utilization, and treats that as direct evidence that an anonymous, unvetted GPU pool isn't reliable or safe enough for a live KYC data flow, so the network chose a permissioned, KYB-gated registry instead of trying to bootstrap an open one.

Solidus status

The registry exists in two layers, both real and running. An off-chain mirror lives inside the compute broker itself: the fast path that live job routing actually reads from. An on-chain, authoritative version lives in three dedicated RocksDB column families (compute_allowlist, compute_nodes, compute_anchors) on Solidus's testnet validator, driven by three transaction types: ComputeAdmit (add an operator), ComputeRegister (the operator's own self-certifying registration, checked against the exact public key it claims), and ComputeRemove. These already exist in the live testnet validator's datadir today, not just in a design document.

Two things temper that "shipped" status honestly. First, admission governance in Phase 1 is a single active validator, not a dedicated multisig or governance body, meaning one validator can today unilaterally admit, remove, or slash a compute operator. Solidus's own internal review flagged this as a hard prerequisite to fix before any real stake is on the line, not a settled design. Second, the registry is functionally empty right now: the live broker reports zero active operator nodes as of this writing. The gating mechanism is built correctly; it hasn't yet been tested against a real population of independent, KYB'd third-party operators.

Proof you can run yourself: curl https://broker.solidus.network/health is live and public, and honestly reports the current node count rather than a curated one. The three on-chain transaction handlers and the single-validator governance gate are visible in source in the public solidusnetwork/protocol repository's solidus-txns crate.