Become a validator
The two network programs, the filing lifecycle, who can file, and what actually changes on approval.
Joining the network as either a new chain or a new validator goes through the same front door: a filing, reviewed by staff. This page covers that process and, deliberately, what happens after approval, because approval by itself changes nothing operationally until two further steps are carried out.
The two network programs
There are two kinds of filing, held in one table because they are the same object with a different payload:
- Chain integration: a request to add a new chain to the network. Its details carry the chain's DID method, RPC endpoint and a contact.
- Validator enrolment: a request to run a node against an existing chain. Its details carry the node's public key, its URL and a contact.
Both are filed as a network application and reviewed by staff before either takes effect.
Lifecycle
A filing moves through a fixed set of states:
submitted → in_review → approved → live, with rejected reachable
from submitted, in_review or approved, and suspended reachable from
live (and reversible back to live).
A filing never moves backward to submitted: once staff have looked at it,
that fact is not undone by accident. Only one open filing per kind is
allowed per organisation at a time; a resubmission reuses the existing
filing rather than opening a second one alongside it.
Who can file
Filing a network application commits the organisation to a review, so it is restricted to an administrator of that organisation. Reading an existing filing, by contrast, is open to any member: seeing where a filing stands is not a decision, and there is no reason to gate it behind the same permission that starts the review.
What happens after approval
Approval is a status change. On its own it does nothing to the running network. Two further steps are what actually let a validator's signature count for anything, and both are required:
- The operator's signer address is added to the signer registry on each chain. Until this happens, any signature the node produces is collected by peers that poll it and then rejected at verification time. See Deploy the contracts for how a chain's signer registry is administered.
- Their node is added to the collector's peer list. Until this happens, no round ever polls the node in the first place, regardless of whether its address is registered. See Join a quorum for the peer list and the checks it enforces.
An approved filing whose operator is missing from either step is not yet a
working validator: it is added to the registry but never polled, or polled
but never counted. live is the state that means both steps are done and
the node is actually contributing to quorum.
The reference number
A filing's ref, the human-readable identifier such as a chain or validator
filing number, is not a stored field. It is derived on read, from the
filing's kind and its id, each time it is needed. There is nothing to keep
in sync between a stored reference and the record it names.