Skip to main content

Consensus Mechanism

Orbinum produces blocks with Aura and finalizes them with GRANDPA, run by a permissioned validator set. Nominated Proof-of-Stake is the target model and is not active.

Block production and finality​

  • Aura (Authority Round) assigns each 6-second slot to one validator in turn; that validator authors the block for its slot.
  • GRANDPA finalizes chains of blocks by vote. Once more than two thirds of the validators vote for a block, it and its ancestors are final — deterministically, not probabilistically. GRANDPA tolerates up to one third faulty validators.

Production and finality are independent: a validator that stops authoring still votes, and blocks keep being produced while finality catches up. See the Substrate consensus documentation for the algorithms themselves.

Parameters​

ParameterValue
Block time6 seconds
Finalityabout 12 seconds
Maximum validators32 (MaxValidators)
Session length600 blocks, about 1 hour
Validator set change latency2 session boundaries, about 2 hours
Session keysAura (sr25519) and GRANDPA (ed25519)

The validator set​

The set is permissioned. Candidates are selected off-chain, and Root records each one with validatorSet.addValidator. The call is accepted only once the account has registered its session keys with session.setKeys, and a session drops any approved validator whose keys are missing, so every member of the set can author. There is no on-chain candidacy and no bond. Removal is also a Root call.

A change takes effect two session boundaries after it is made: at each rotation the session pallet queues the set for the session after next. Operators should expect about two hours between approval and their first slot.

Minimum author version​

Each block declares the version of the node that authored it through a mandatory inherent, validatorSet.noteAuthorVersion. Root can set a floor with validatorSet.setMinAuthorVersion; a block below it is invalid, so a lagging validator loses its slots but keeps importing and voting. Setting a floor needs at least two thirds of the approved set to have declared that version or newer within the last session; lifting it needs no quorum. The declaration is self-reported — it coordinates upgrades among known operators and is not a security boundary. Operator view: Minimum node version.

Separately, the runtime verifies Groth16 proofs through the host function bn254_groth16_verify, which nodes provide from version 0.4.0. A node must run 0.4.0 or newer to import blocks at all.

What a validator earns​

  • Spend fees of the private transfers and unshields in the blocks it authors, credited as pending fees to its validator account and claimed with claim_fees — see Spend Fees.
  • EVM priority tips of the blocks it authors, paid to its validator account.

The author is the session validator at the Aura authority index that sealed the block, so a validator that registered its keys from another account still earns. EVM block.coinbase is the zero address: a validator's sr25519 account has no H160 form. Ordinary Substrate transaction fees and the EVM base fee are burned. Staking rewards belong to the NPoS model described in Staking & Rewards.

No slashing​

The runtime configures GRANDPA with KeyOwnerProof = Void and no equivocation reporting, and the session pallet with no disabling strategy. An equivocation proof cannot be constructed, and a misbehaving validator is never disabled automatically; removing one is a Root call. Slashing conditions belong to the NPoS model.