Consensus and finality
The draft QDPoS protocol combines elected validators, scheduled blocks, and finality derived from signed block headers.
Proposed parameters
Section titled “Proposed parameters”| Parameter | Draft value |
|---|---|
| Validator seats | 53 |
| Slot duration | 8 seconds |
| Round | 53 slots |
| Finality threshold | 36 of 53 validators |
| Election check | Every 24 rounds |
| Seat changes per check | At most one, gated by finality |
ROOT holders split voting weight among validators. A vote names 20 to 53 validators with at most 5% of the account’s weight each, validator accounts cannot vote, and an account holding more than 5% of ROOT’s supply carries no vote weight. Weight follows liquid ROOT balances; the draft does not require locking or bonding. Validators and voting lists the rules.
The active set validates in a deterministic schedule. A missed slot remains empty.
Production and finality
Section titled “Production and finality”A block’s inclusion and its finalization are separate events. Block production continues while later signed headers accumulate the votes needed to finalize earlier blocks.
The draft uses two header fields, maxHeightPreviouslyForged and maxHeightPrevoted, to derive implied votes. Its analysis gives an earliest finalization 71 blocks later. Timing depends on validator order and availability; the paper’s estimates are derived values, not measurements of a deployed network.
For the proposed API, confirmations measures how far the tip has advanced. finalized: true is the signal for an irreversible credit or destination-chain action.
Faults and stalls
Section titled “Faults and stalls”The draft distinguishes two guarantees:
- Safety: conflicting finalization is prevented with at most 18 Byzantine validators in a stable set, or 16 beside a one-seat transition.
- Progress: finality continues with up to 17 crashed validators. This claim does not cover coordinated Byzantine forking.
Without new finality, the proposed response is:
- After four rounds: raise an alert.
- After 24 rounds: pause user transactions.
A permanent loss of enough seats requires a coordinated recovery release; the threshold does not automatically fall.
Finality window details, some system-message rules, and penalty durations remain open in the draft. Current runtime behavior must be checked against the matching Heartwood release.