> ## Documentation Index > Fetch the complete documentation index at: https://seilabs-docs-evm-cookbook.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Twin Turbo Consensus: Sei's High-Speed Blockchain Consensus > Explore how Sei's Twin Turbo consensus mechanism achieves higher transaction throughput by separating block building from consensus, with detailed explanations of the protocol's design and benefits. ## Introduction Sei's consensus mechanism, often called Twin Turbo Consensus, is a set of optimizations designed for low block finality times. The target is approximately 400 milliseconds. Sei does not use a new consensus algorithm to reach this finality. Instead, Sei significantly enhances the underlying Tendermint Byzantine Fault Tolerant (BFT) consensus engine and tunes its configuration aggressively. The consensus engine also integrates tightly with Sei's parallel execution layer and the SeiDB storage system. The goal is near-instant transaction confirmation, which supports a new class of high-performance dApps, particularly dApps built for the EVM. ## Core concept: pipelined & parallelized consensus Sei reaches sub-second finality by aggressively optimizing and parallelizing the standard BFT consensus flow. Traditional Tendermint proceeds through distinct rounds of propose, prevote, precommit, and commit, somewhat sequentially, for each block height. In contrast, Sei heavily pipelines these operations and integrates them closely with parallel transaction execution. The optimized flow includes these enhancements: 1. **Aggressive timeout configuration:** Sei uses heavily tuned Tendermint consensus parameters. Configuration settings (for example, `UnsafeProposeTimeoutOverride` and `UnsafeCommitTimeoutOverride`) can enforce much shorter durations for block proposal, voting, and commit rounds than standard Tendermint configurations. This contributes directly to the sub-second target block time. Faster gossip propagation for consensus messages further reduces communication latency between validators. The `unsafe-overrides-enabled` flag in the `[consensus]` section of the node config gates these `Unsafe*TimeoutOverride` fields. This flag defaults to `false`. With the default, the node ignores the overrides and uses the on-chain timeout consensus parameters instead. The node applies the overrides only when `unsafe-overrides-enabled` is set to `true`. During the transition period, it also applies them while the on-chain timeout parameters still match the legacy values. In practice, the on-chain consensus parameters should govern timeout tuning, not these unsafe per-node overrides. 2. **Mempool management & transaction preparation:** Even before the block proposal for height `H` formally begins, validators can start to process transactions intended for that block. This work includes collecting transactions from the network, decoding them concurrently (`DecodeTransactionsConcurrently`), analyzing potential state dependencies (`GenerateEstimatedWritesets`), and potentially pre-fetching required state data from SeiDB. This "pre-consensus" preparation minimizes the work needed when the actual proposal for height `H` arrives. 3. **Optimized BFT rounds with parallel execution integration:** The main optimization is the close integration with Sei's parallelization engine. When a validator receives a block proposal for height `H`, it can start execution before the prevote and precommit rounds complete: * The validator dispatches the block's transactions to the parallel execution engine (`ProcessTXsWithOCC`, `DeliverTxBatch`). * Transactions execute *optimistically and concurrently* on multiple worker goroutines. Mechanisms such as `CacheMultiStore` buffer the state changes. * At the same time, the validator takes part in the standard BFT prevote and precommit voting rounds for the proposed block `H`. 4. **Rapid finalization and commit:** Transaction execution overlaps significantly with the consensus voting process. This greatly reduces the time between reaching 2/3+ precommits for block `H` and having the resulting state changes ready to commit. When consensus is reached, the validated state changes that were buffered during parallel execution are committed efficiently to the underlying SeiDB storage layer. This commit uses the high I/O capabilities of SeiDB. **Optimized & pipelined consensus** * Transaction collection & analysis * State prefetching (SeiDB) * Block proposal reception & initial validation * BFT voting (prevote/precommit) * Parallel TX execution (optimistic) *(Consensus reached)* → **Finalize state & commit to SeiDB** This diagram shows the conceptual overlap. Transaction preparation feeds into a process where BFT voting happens *alongside* parallel transaction execution. The preceding concurrent work lets the final commit to SeiDB happen quickly after consensus. ## Performance impact for EVM developers This optimized consensus flow has these benefits: * Sei has instant, deterministic finality. A transaction is final as soon as its block is committed, within the target block time of approximately 400 ms. There is no probabilistic confirmation window or multi-block wait. This removes the long confirmation waits that are common on other chains. * The low latency improves the user experience. Interactions feel instantaneous, which brings dApps closer to traditional web services. * The speed makes previously impractical on-chain applications possible, for example high-frequency trading components, real-time price oracles (critical for stable DeFi), and responsive on-chain games. * Complex DeFi workflows that involve multiple transactions (for example, approve-swap-stake) can execute in sequence within roughly a second. This improves capital efficiency and simplifies user interactions. Sei keeps core EVM compatibility alongside these performance gains. This includes standard gas models and support for Solidity, Vyper, and common Ethereum development tools. ### Leveraging fast finality in Solidity The rapid block times enable and encourage these development patterns: **1. Minimal confirmation waits:** Off-chain applications and scripts should rely on one block confirmation (`txResponse.wait(1)`) for probabilistic finality. This significantly speeds up application logic that depends on transaction inclusion. ```javascript theme={null} // Fast transaction submission leveraging ~400ms finality async function sendTransaction(tx) { // ... prepare transaction ... const signedTx = await wallet.signTransaction(transaction); const txResponse = await provider.sendTransaction(signedTx); // Wait for ONE block confirmation const receipt = await txResponse.wait(1); // Returns quickly console.log(`Tx ${receipt.transactionHash} confirmed in block ${receipt.blockNumber} (~400ms)`); return receipt; // Proceed with logic assuming finality } ``` **2. Practical multi-step interactions:** Complex sequences of multiple dependent transactions become efficient and user-friendly. ```javascript theme={null} // Example: Multi-step DeFi operation (Approve + Swap + Deposit) async function executeDeFiStrategy(tokenAddress, amount) { const approveTx = await erc20.approve(ROUTER_ADDRESS, amount); await approveTx.wait(1); // ~400ms const swapTx = await router.swapExactTokensForETH(/* ... */); await swapTx.wait(1); // ~400ms const depositTx = await lendingPool.deposit(/* ... */); await depositTx.wait(1); // ~400ms // Total time ~1.2 seconds console.log('Multi-step strategy completed.'); return { /* ... results ... */ }; } ``` **3. Time-sensitive contract logic:** Smart contracts can implement logic that is sensitive to short time intervals, measured reliably in blocks. * **Short-duration auctions and votes:** Contracts can define processes that resolve within seconds or minutes. They can use `block.number` for precise timing, based on the block interval of approximately 400 ms. * **High-frequency oracles:** Oracles can push updates much more frequently, for example every few seconds (a small number of blocks). This gives DeFi protocols fresher data. ```solidity theme={null} // Example: High-Frequency Oracle Update Constraint contract HighFrequencyOracle { uint256 public lastUpdateBlock; // Allow update every 5 blocks (~2 seconds) uint256 public updateFrequency = 5; function updatePrice(bytes32 asset, uint256 price) external /* ... */ { // Enforce minimum block interval between updates require(block.number >= lastUpdateBlock + updateFrequency, "Update too frequent"); // ... update price state ... lastUpdateBlock = block.number; // ... emit event ... } // Check price freshness (e.g., < 25 blocks = ~10 seconds) function isPriceFresh(bytes32 asset) external view returns (bool) { return block.number - lastUpdateBlock < 25; } } ``` ### Compatibility and future directions Sei's consensus optimizations keep full compatibility with the EVM standard. Existing smart contracts, dApps, and developer tools work normally. Ongoing and future work focuses on further optimizing the pipeline. It includes: * Advanced state management techniques, such as predictive loading and EVM-specific caching integrated with SeiDB * Potential bytecode optimizations or JIT compilation for the EVM execution layer * Building cross-chain communication protocols that use Sei's fast finality This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.