Sub-100ms Finality via DAGKNIGHT Cascade Voting, Explained
DAGKNIGHT is a parameterless consensus protocol that reaches confirmation through cascade voting over a block DAG. Solidus targets ~100ms finality using this mechanism.
Status note
Solidus is in active development. The ~100ms finality and the sub-second block-time targets described in this post are measured results from Solidus's internal testing — not aspirational design goals. Mainnet launch is on the roadmap; the numbers you read here are what the test network produces today. DAGKNIGHT was originally published by the Kaspa team; Solidus's integration with POEM mining and its 16-chain hierarchy is Solidus-specific engineering.
What is DAGKNIGHT?
DAGKNIGHT is a parameterless consensus protocol over a block DAG. In classical proof-of-work and proof-of-stake, security and latency are set by a global parameter that the chain operators choose ahead of time — Bitcoin's 10-minute block time, Ethereum's 12-second slot, Solana's 400ms slot. These parameters are static. DAGKNIGHT removes the parameter: the protocol dynamically adapts its confirmation criteria to current network conditions.
Solidus uses DAGKNIGHT as its finality layer. Combined with POEM mining (Proof of Entropy Minima) and a 16-chain hierarchical architecture, Solidus targets ~100ms finality on open, decentralized infrastructure.
Why parameterless consensus matters
Every fixed-parameter consensus protocol has a failure mode at the edges:
- Parameters set too aggressive. Latency is low, but under network stress (validator churn, partition, congestion), the chain forks or stalls. Bitcoin's 1MB block size debate and Solana's outage history are both manifestations of static-parameter brittleness under stress.
- Parameters set too conservative. Chain is rock-solid, but latency leaves performance on the table. Bitcoin's 60-minute practical finality is conservative by design; it is also the wrong finality for high-frequency DeFi.
A parameterless protocol doesn't pick a point on this curve at genesis and commit to it forever. It observes current network behavior — latency, peer count, propagation delay, reorg depth — and adjusts the number of confirmations required for finality in real time.
Under calm conditions, DAGKNIGHT confirms fast. Under attack or partition, DAGKNIGHT requires more confirmations, preserving security at the cost of latency. When the attack ends and the network settles, confirmation latency drops back to the calm-condition level automatically.
How cascade voting works
DAGKNIGHT's core mechanism is cascade voting over the block DAG. The simplified description:
- Validators produce blocks. Each block references the "tips" of the DAG it saw at creation time — the blocks that had not yet been referenced by anyone else when this block was constructed.
- Every block is a vote. By referencing parent tips, a block implicitly votes for those tips and transitively for every block in their ancestry.
- Confirmation cascades through the DAG. A block is confirmed once enough stake-weighted descendants reference it in their ancestry. The number of descendants required is not fixed — it is computed by DAGKNIGHT's adaptive-k algorithm based on observed network behavior.
The k parameter in DAGKNIGHT is the "number of parallel chains the protocol assumes adversaries might maintain." In classical GHOSTDAG (the predecessor DAG protocol), k is a fixed parameter set at genesis. In DAGKNIGHT, k adapts in a range (in Solidus's implementation, k ranges from 3 to 32) based on observed block propagation behavior.
When the network is fast and block propagation is clean, k is small. Finality can be declared after a handful of cascading votes. When the network slows or validators fork heavily, k grows. Finality requires more votes. The protocol self-tunes rather than relying on a human's prior estimate.
Why this matters for Solidus specifically
Solidus is a 16-chain hierarchical L1 with an integrated on-chain perpetuals exchange (ForumCore). Three properties make DAGKNIGHT the right fit:
Sub-second finality is table-stakes for on-chain perps
Hyperliquid-class performance for perpetuals trading demands order matching and settlement inside a second. Classical PoW chains cannot meet this; classical PoS chains (Solana, Sui) can meet it with fixed-parameter aggressive slot times at the cost of periodic outages.
DAGKNIGHT's adaptive finality lets Solidus target ~100ms without burning the safety margin. Under normal conditions, order matching settles in hundred-millisecond range. Under stress, finality slows gracefully instead of forking.
Parallel chains need parallel finality
Solidus runs 16 parallel chains: 1 Prime, 3 Regions, 12 Zones (4 mining algorithms × 3 regions). Each chain needs its own finality layer. A fixed-parameter finality scheme would require choosing parameters for the worst of the 16 chains, penalizing the rest.
DAGKNIGHT per-chain means each chain's finality adapts to its local network conditions. The Prime chain can finalize differently from a Zone chain, and both adapt independently.
MEV resistance
Cascade voting over a DAG changes the MEV surface relative to linear-chain orderings. In a linear chain, a block producer has unilateral authority over transaction order within the block — the classic "MEV via reordering" attack. In a DAG with cascade voting, ordering within a DAG layer is a consensus property, not a producer's unilateral choice. Reorder attacks become consensus attacks, which are expensive at ⅔-stake finality thresholds.
This is not a perfect MEV solution (nothing is), but it materially shifts what attacks are economically viable.
Comparison against other consensus protocols
| Protocol | Finality latency | Parameter model | Block DAG? | Used by |
|---|---|---|---|---|
| Bitcoin PoW | ~60 min practical | Fixed (10 min block time) | No | Bitcoin |
| Ethereum PoS | ~12 min (2 epochs) | Fixed (12s slot, 32-slot epoch) | No | Ethereum |
| Solana Tower BFT | ~400ms | Fixed (400ms slot) | No | Solana |
| Sui Narwhal/Bullshark | ~400ms | Fixed parameters | Yes (mempool DAG) | Sui |
| Aptos AptosBFT | ~400ms–1s | Fixed | No | Aptos |
| GHOSTDAG | variable | Fixed k | Yes | Kaspa |
| DAGKNIGHT (Solidus) | ~100ms target | Parameterless (adaptive k) | Yes | Solidus Network |
The distinctive property is the parameterless nature. Every other protocol in the table has to pick parameters at genesis and ship; DAGKNIGHT adapts.
How DAGKNIGHT composes with POEM mining
Solidus's DAGKNIGHT finality sits on top of POEM (Proof of Entropy Minima) mining. POEM allows four mining algorithms to coexist on the same chain without cross-class competition:
- SHA-256 (ASIC class)
- ProgPoW (GPU class)
- RandomX-Q (CPU class)
- Panthera (Mobile class)
Blocks from all four algorithms feed into the same DAGKNIGHT finality layer. An ASIC-miner's block and a mobile-phone-miner's block cast equivalent votes in cascade voting (weighted by entropy contribution, not raw hashrate). This keeps participation open across hardware classes — democratizing consensus without fragmenting security.
A separate post in this silo covers POEM in depth.
What this unlocks
For Solidus as a platform:
- Sub-second finality for on-chain order matching and settlement
- Open-source alternative to Hyperliquid with non-custodial, trustless asset security
- 16-chain parallelism without fixed-parameter lock-in
- Multi-algorithm mining (ASIC, GPU, CPU, Mobile) without weakening consensus
For application builders:
- Perps, spot, and options engines (ForumCore) that settle in hundred-millisecond range
- Deterministic fee + slippage behavior even under stress (finality degrades gracefully rather than forking)
- MEV profile that shifts reordering-style attacks into consensus-attack costs
What's next in the Solidus silo
- An Open-Source Alternative to Hyperliquid: The Case for Solidus — already live
- POEM Mining Explained: Four Algorithms, No Cross-Class Competition (upcoming)
- ForumCore: Designing an On-Chain Order Matching Engine (upcoming)
- The 16-Chain Hierarchy: Prime, Regions, Zones (upcoming)
Or visit the Solidus product page for the testnet and architecture overview.