Attestra

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:

  1. 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.
  2. 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.

On this page