Apply to Join the Set

Selection happens off-chain. You send an email, a person reads it, and if you are accepted the team makes one sudo call. There is no on-chain application and no queue — pallet-validator-set only records the decision.

---

Before you email

All of these must already be true.

• Your node is synced — system_health reports isSyncing: false
• session.nextKeys(yourAccount) returns your session keys
• author_hasSessionKeys on those keys returns true — the chain having your keys does not mean your node does
• Port 30333 is reachable from the internet
• Your node is visible on telemetry under a name you recognise

If any of these is not done, finish Run a Validator Node first.

---

What to send

Email contact@orbinum.net with the subject Testnet validator application — <your name>.

Field	Required	Why it is asked
SS58 address	Yes	The sole argument to addValidator(who). Everything else is context
Operator name / website	Yes	Who we are adding — a company page, a GitHub org, or a personal handle
Infrastructure experience	Yes	Networks you already validate, or what you run instead. "First validator" is a real answer, not a disqualifier
Server provider and region	Yes	Both are selection factors — see Hosting providers
Contact handle	Yes	Discord or Telegram, so we can reach you when your node misbehaves
Telemetry node name	Yes	The name your node reports to telemetry.orbinum.network. We confirm it is synced there before approving — a node we cannot see cannot be approved
Monitoring setup	Optional	Whether you will notice an outage before we do

A human review, not a scored form: no SLA, no guaranteed slot — see How slots are assigned. A short honest email reads better than a long one.

---

What happens next

1. The team calls validatorSet.addValidator(<your SS58>) via sudo. The chain emits ValidatorAdded.
2. Your account appears in validatorSet.approvedValidators — check it under Developer → Chain state.
3. At the next session rotation the new set is queued; at the one after it becomes the active set. Roughly two hours, sessions being 600 blocks — nothing visible happens in that window, and that is expected.
4. Your node starts authoring. You will see it proposing blocks in the logs, and your address appears on the telemetry dashboard.

---

If addValidator fails

Error	Cause	Fix
NoSessionKeys	session.setKeys was never submitted, or did not finalize	Redo step 6 and confirm session.nextKeys returns your keys
(no error — added, but never authors)	The chain has your keys; your node does not	Step 7 — author_hasSessionKeys returns false. Rotate on the node itself and resubmit setKeys
AlreadyValidator	The account is already in the approved set	Nothing to do — wait for the rotation
TooManyValidators	The 32-validator cap is reached	The set is full; the team will tell you

---

The extrinsics that govern membership

For reference: three, and only three. Two are sudo-only; the third is yours.

Extrinsic	Origin	Effect
addValidator(who)	sudo	Adds an account to the approved set. Requires session keys
removeValidator(who)	sudo	Force-removes an account
deregisterValidator()	you, signed	Leaves the set voluntarily

Retired calls

Earlier versions had a self-registration flow — registerValidator, approveValidator, rejectValidator. Those were removed. Any guide that tells you to submit a candidacy on-chain is describing a runtime that no longer exists.

---

Leaving the set

Either you call deregisterValidator(), or sudo calls removeValidator(who); both take effect at the next session rotation. What that does to your relay binding and fees is in Relay Setup and Rewards.