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

Three things must already be true. An application from an account without session keys cannot be actioned at all — the call would fail on-chain.

• Your node is synced — system_health reports isSyncing: false
• session.nextKeys(yourAccount) returns your key blob
• 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	The set is concentrated on a few providers today; diversity is a genuine selection factor
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

Keep it short

This is a human review, not a scored form. There is no SLA, no guaranteed acceptance, and the set is capped at 32 with limited testnet slots. 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.
4. Your node starts authoring. You will see it proposing blocks in the logs, and your address appears on the telemetry dashboard.

Nothing visible happens in step 3's window. That is expected — sessions are 600 blocks and a set change always waits for two boundaries.

---

If addValidator fails

Error	Cause	Fix
NoSessionKeys	session.setKeys was never submitted, or did not finalize	Redo step 7 and confirm session.nextKeys returns your blob
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

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 emit ValidatorRemoved and take effect at the next session rotation.

Both also clear your EVM relay binding automatically — a binding must not outlive the membership that authorised it. Re-entering means registering a relay address again.

Fees you already earned are untouched. Pending relay fees survive removal and stay claimable — see Relay Setup and Rewards.

---

Next Steps

• Relay Setup and Rewards — register your relay address and start earning
• Validator Operations — day-to-day monitoring and maintenance