Helix-ZK: Leaderless DAG Consensus

A partially synchronous DAG protocol that orders proof batches, not individual transactions.

DAG Overview

Round rRound r+1Round r+2Round r+3
Validator A
Validator B
Validator C
Validator D
Strong citation

Each block (vertex) in Helix-ZK references the tips of previous rounds, forming a directed acyclic graph. There is no explicit vote message round. A vertex that references another implicitly supports all its ancestors, and consensus emerges from these DAG references.

Timing Model

Slot
12 seconds
Block / Vertex
400 ms
Round time
~0.6–1.0s

Each slot spans ~30 blocks. Blocks act as ordering heartbeats even without proofs. They maintain the DAG structure and give validators a consistent time reference.

Leader Election

Leader election is hash-based and requires no verifiable random functions (VRFs). The leader for each slot is determined by hashing the epoch seed, the slot index, and the validator's public key:

pseudocode
r = H(seed_e || slot_i || pk_val)

The MinRoot VDF (Sloth-based Wesolowski Friendly) generates unbiasable epoch randomness. No single validator can predict or influence the seed before it is revealed.

This construction is inherently post-quantum: it relies only on SHA3-256 and the sequentiality assumption, with no lattice or group-theoretic primitives.

3-Chain Finalization

A block is finalized when it is part of a chain of 3 consecutive ratified leaders. A leader is ratified when its vertex receives strong citation, meaning vertices representing more than 2/3 of total stake reference it.

Under normal network conditions, this yields finalization in 1.8–3.0s. The three-chain rule provides Byzantine fault tolerance: conflicting blocks cannot both be finalized unless the adversary controls at least 1/3 of total stake.

Fee Market

QBit uses an exponential damping base fee mechanism inspired by EIP-1559. The base fee adjusts each slot based on network utilization, keeping transaction costs predictable and resistant to fee manipulation.

Forced inclusion: users can submit transactions directly to validators via a dedicated inclusion path, bypassing Sentry mempools. No coordinator can indefinitely suppress a transaction.

Global cap: forced-inclusion transactions are limited to 5% of block capacity per slot, preventing denial-of-service attacks on the direct path while preserving the censorship-resistance guarantee.