---
title: "Twin Turbo Consensus"
sidebarTitle: 'Consensus'
description: "How Paxeer's consensus stack combines Twin Turbo pipelining with machineRFT negative attestations to achieve sub-second deterministic finality."
keywords: ['twin turbo consensus', 'machineRFT', 'consensus', 'finality', 'paxeer', 'bft']
---

> **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version.

## 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.

<Columns cols={2}>
  <Card horizontal title="Pre-Consensus (TX Preparation)">
    - Transaction collection and analysis
    - Concurrent decoding
    - State prefetching from SeiDB
  </Card>
  <Card horizontal title="Optimized BFT (Voting + Concurrent Execution)">
    - Block proposal reception
    - BFT voting (prevote/precommit)
    - Parallel TX execution (optimistic)
  </Card>
</Columns>

_(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

| Component | Role | What it optimizes |
|-----------|------|-------------------|
| **Twin Turbo** | Pipelined BFT engine | Overlaps proposal, voting, and execution phases |
| **machineRFT** | Negative attestation layer | Removes execution from the consensus critical path |
| **Parallelization engine** | Concurrent TX execution | Processes non-conflicting transactions in parallel |
| **SeiDB** | Storage layer | High-throughput state reads/writes |

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

| Metric | Value |
|--------|-------|
| Average block time | ~250ms |
| Record sustained low | 0.45ms |
| Peak throughput | 5,000 TPS |
| Finality | Deterministic (instant) |
| Reorgs | Zero |
| Consensus path | Network RTT + ed25519 signing |

## 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.