The QGOV Consensus

QGOV combines delegated proof of stake with constitutional safeguards. The goal is to keep the network scalable in normal operation while preserving accountability in exceptional cases.

Q Node and Network Roles

The Q node is the client software that forms the peer-to-peer network. It is used by:

  • Root Nodes
  • Validator Nodes
  • Tech-savvy users running their own infrastructure

All of these participants connect to the same chain state and protocol rules, but with different responsibilities.

Consensus Model

QGOV applies delegated proof of stake (DPoS):

  • Consensus is produced by a validator set, not by all peers.
  • Validators are elected by token holders from technically capable candidates.
  • Voting power is proportional to stake locked for validation.
  • Root Nodes can exclude validators who violate constitutional rules.
  • Validators produce blocks in a rotation-based cycle.

This design ties protocol control to delegated economic stake while maintaining governance checks and balances.

Validation Cycle and Epochs

A validation cycle is a sequence of blocks with a fixed validator set. Its last block (the transition block) defines the validator set for the next cycle.

Within a cycle:

  • Validators are ordered lexicographically.
  • Any validator can propose a block.
  • The network prefers the block from the validator whose turn it is.

The legacy technical concept uses an epoch length of 101 blocks. The mechanism remains functional even if the number of validators differs from epoch length.

Dynamic Validator Set

The validator set is updated through a three-level process:

  1. Long list: all addresses with non-zero validation stake.
  2. Short list: top-ranked addresses by total stake, including active and standby capacity.
  3. Snapshot: a per-cycle copy of the short list, included in the transition block.

This process allows validator membership to adapt continuously as stake allocations change.

Consensus Engine Context

Validators reach block agreement with a Clique-style proof-of-authority sealing process.
This emphasizes liveness and tolerates temporary forks before practical finality is reached after sufficient confirmations.

The current reference implementation of the QGOV node is based on a fork of the Ethereum geth client. The public implementation repository is available at Q-Client on GitLab.

Alternative BFT-style approaches were considered during early research phases, with stronger immediate-finality guarantees but stricter networking requirements.

State Transitions and Transactions

QGOV implements the Ethereum Virtual Machine (EVM), which means:

  • Account-based balances (not UTXO).
  • Pseudonymous accounts controlled by key pairs.
  • State transitions via signed transactions, nonce handling, and gas fees.
  • Smart contracts deployed as onchain bytecode.

This provides direct compatibility with Ethereum tooling and Solidity-based development patterns.

Block Reward Distribution

New QGOV tokens are minted as part of block production. Instead of paying the full reward directly to the block producer, rewards are routed into a distribution pool smart contract and claimed by eligible participants.

This supports a broader incentive model across the ecosystem.

Summary

The QGOV consensus architecture combines:

  • Stake-weighted validator selection
  • Rotation-based block production
  • Dynamic validator set updates
  • EVM-compatible transaction execution
  • Governance safeguards through Root Node oversight

Together, these elements provide scalable operation with constitutional accountability.