Becoming a Validator
Orbinum's testnet validator set is permissioned: you run a node, register session keys on-chain, and the Orbinum team adds your account with a single sudo call. There is no bond, no stake, no nomination and no slashing.
This section is the whole path. You should not need to leave it.
What a validator does
Authors blocks. Aura assigns slots round-robin among the active set. Your node builds a block when its slot comes up, every 6 seconds.
Finalizes blocks. GRANDPA votes on chains rather than individual blocks. A block is final once more than two thirds of the set has voted for a chain containing it — roughly 12 seconds.
Relays private transactions. unshield and private_transfer arrive as
unsigned extrinsics with the fee sealed inside the ZK proof. Every active
validator is an implicit relayer; including one of these calls credits the fee to
your registered relay address. This is the only income a validator earns.
What entry is, and is not
Most of what you know from other Substrate networks does not apply here yet. The
runtime has no pallet-staking at all:
| Concept | Orbinum testnet today |
|---|---|
| Entry | Off-chain evaluation, then one sudo validatorSet.addValidator(who) |
| Bond / stake | None. Session keys cost no deposit |
| Nomination | Not implemented — no pallet-staking in the runtime |
| Slashing | None. Equivocation reports cannot even be constructed |
| Election | None. The approved set is the active set |
| Set size cap | 32 validators |
| Exit | deregisterValidator() (yours) or removeValidator(who) (sudo) |
| Income | Relay fees from the shielded pool. Ordinary transaction fees are burned |
There is no on-chain application, no queue you can join, and no way to force entry. Sudo is the only origin that can add you. If nobody at Orbinum acts on your email, nothing happens — see Apply to Join the Set.
The five steps
Each one links to the page that covers it. The order is not a suggestion — two of the steps fail outright if taken early.
- Provision the server — dedicated CPU, an open P2P port, and an account with a little ORB.
- Run the node and generate session keys — Docker
Compose, sync, then
author_rotateKeys. - Submit
session.setKeys— puts your Aura and GRANDPA keys on-chain, under your account. - Apply by email — the team reviews and calls
addValidator. - Register your relay address — after approval, so you earn from the blocks you author.
session.setKeys must be finalized before the team calls addValidator, or
the call is rejected with NoSessionKeys — an approved account with no keys would
hold a slot in the schedule and never produce a block.
registerRelayer must come after approval, or it is rejected with
NotValidator.
Timing
Nothing about a set change is instant. The two numbers that matter:
| Parameter | Value |
|---|---|
| Block time | 6 seconds |
| Session length | 600 blocks ≈ 1 hour |
| Set change takes effect | 2 session boundaries ≈ 2 hours |
A validator added by sudo is queued at the next session rotation and becomes active at the one after it. Budget two hours between the team's call and your first authored block, and do not treat silence in that window as a failure.
Next Steps
- Validator Requirements — hardware, ports, and the accounts you need
- Run a Validator Node — deploy, sync, and register session keys
- Apply to Join the Set — what to send, and what happens after
- Consensus Mechanism — how Aura and GRANDPA work here