Twin Turbo Consensus

Two layers, one consensus stack

Paxeer's consensus is a two-layer stack. Twin Turbo provides the pipelined BFT engine that overlaps proposal, voting, and execution phases. machineRFT layers on top with a negative-attestation model that transforms consensus from a state-verification problem into a pure ordering problem.

Together, they deliver ~250ms average block time, a 0.45ms record low, 5,000 TPS, and instant deterministic finality with zero reorgs.

Layer 1: Twin Turbo (pipelined BFT)

Twin Turbo is an aggressively optimized CometBFT engine. It achieves sub-second block times through deep pipelining of the standard BFT flow.

What Twin Turbo does

Traditional CometBFT proceeds through propose, prevote, precommit, and commit sequentially for each block. Twin Turbo overlaps these phases:

1. Aggressive timeout tuning - configuration overrides (UnsafeProposeTimeoutOverride, UnsafeCommitTimeoutOverride) enforce much shorter durations for each BFT round. Faster gossip propagation reduces inter-validator communication latency.

2. Pre-consensus transaction preparation - before a block proposal arrives for height H, validators are already collecting transactions, decoding them concurrently (DecodeTransactionsConcurrently), analyzing state dependencies (GenerateEstimatedWritesets), and pre-fetching data from SeiDB.

3. Optimistic parallel execution - when a validator receives a proposal for height H, it dispatches transactions to the parallelization engine immediately, running execution concurrently with prevote/precommit voting. State changes are buffered via CacheMultiStore until consensus is reached.

4. Rapid commit - because execution overlaps with voting, the gap between achieving 2/3+ precommits and having state changes ready for commit is near-zero.

(Consensus reached) → Finalize state and commit to SeiDB

Layer 2: machineRFT (negative attestation)

Twin Turbo makes the pipeline fast. machineRFT changes what validators agree on.

The problem with positive attestation

Every major BFT protocol (PBFT, Tendermint, HotStuff) uses a positive attestation model: validators execute transactions, verify state transitions, and vote to commit. Execution is on the consensus critical path, which prevents sub-second finality.

machineRFT inverts the model

machineRFT uses negative attestation. Instead of voting on what did happen, validators agree on what did not happen:

1. Order without executing - the consensus critical path handles pure transaction ordering, not state verification.
2. Sign negative attestations - validators cryptographically attest they have not observed conflicting transactions for the same state keys.
3. Execute after consensus - state transitions happen after the block is committed, not during the voting phase.
4. Enforce via fraud proofs - validators who sign false negative attestations are slashed through a post-consensus fraud-proof mechanism.

This reduces the consensus critical path from network latency + full transaction execution to network latency + ed25519 signing operations.

Theoretical foundation

The SOSP 2003 paper "Separating Agreement from Execution for Byzantine Fault Tolerant Services" (Yin et al.) proved that separating agreement from execution improves fault tolerance: 3f+1 replicas for agreement, but only 2f+1 for execution. Tendermint's thesis later formalized this through TMSP. machineRFT takes this to its logical conclusion.

How the layers compose

Twin Turbo makes the pipeline fast. machineRFT makes the consensus decision a pure ordering problem. The parallelization engine handles execution concurrently. SeiDB provides storage throughput.

Performance

What this means for developers

• No confirmation delays - a confirmed transaction is final.
• Predictable latency - the consensus path is bounded by network propagation, not computation.
• M2M-ready - designed for high-frequency automated transactions from autonomous agents.
• Standard EVM - the consensus stack is transparent to smart contract developers.