Sei Giga Overview: The Fastest EVM Blockchain

A comprehensive technical overview of Sei Giga - a high-performance blockchain platform combining EVM compatibility with groundbreaking consensus, execution, and storage innovations for unprecedented throughput and sub-second finality.

Introduction

Sei Giga represents a high-performance blockchain platform designed to address the persistent challenges of the “blockchain trilemma”: the difficulty of simultaneously optimizing for security, decentralization, and performance. The platform combines current optimizations with upcoming architectural innovations to achieve exceptional performance while maintaining security guarantees and developer experience.

Current Features: Sei operates with Twin Turbo consensus optimizations, parallel execution capabilities, and SeiDB storage, delivering significant performance improvements over traditional blockchains.

Upcoming Features: Advanced features including Autobahn consensus, multi-proposer architecture, and 5 gigagas throughput targets are in development and represent the next evolution of the platform.

Current Architecture

Sei’s current system delivers significant performance improvements through three core components:

1. Twin Turbo Consensus

The current consensus mechanism achieves ~400ms block times through aggressive optimization of the Tendermint BFT consensus engine. Key features include:

• Pipelined block processing
• Optimistic transaction execution during consensus
• Aggressive timeout configurations
• Parallel transaction decoding and validation

Learn more about Twin Turbo Consensus →

2. Parallel Execution Engine

Sei implements Optimistic Concurrency Control (OCC) for parallel transaction execution:

• Multiple CPU cores process non-conflicting transactions simultaneously
• Automatic conflict detection and resolution
• Maintains deterministic execution order
• Compatible with standard EVM semantics

Learn more about the Parallelization Engine →

3. SeiDB Storage System

A specialized database optimized for blockchain workloads:

• Multi-level caching for hot state data
• Optimized Merkle Patricia Trie structure
• Concurrent state access controls
• Efficient state versioning and pruning

Learn more about SeiDB →

Upcoming Sei Giga Architecture

The next evolution of Sei Giga will introduce three key innovations designed to achieve target performance characteristics:

1. Asynchronous Execution Model (Upcoming)

A planned architectural enhancement will implement complete separation of consensus and execution. Unlike traditional blockchains where these processes are tightly coupled, the upcoming Sei Giga architecture will reach consensus solely on the ordering of transactions within a block, not the resulting state change.

Asynchronous Execution Architecture

Traditional Blockchain

1. Order Transactions
2. Execute & Compute State
3. Reach Consensus on State
4. Finalize Block

⚠️ Execution delays consensus

Sei Giga Model

1. Order Transactions
2. Consensus on Order
3. Finalize Block n

Parallel Process:

• Execute Block $n - 1$
• Commit State in Block $n+x$

✓ Consensus proceeds independently

This approach leverages the key property of deterministic execution:

Lemma 1 (Deterministic Execution): Given the same initial state ($S_{init}$) and the same ordered sequence of transactions (${tx}_1, {tx}_2, ..., {tx}_n$), all honest nodes executing these transactions will arrive at the exact same final state ($S_{final}$).

Key benefits of this model:

• Non-blocking consensus: Heavy computational blocks don’t delay consensus
• Pipelined processing: Multiple blocks can be in different stages simultaneously
• Optimized resource usage: Consensus and execution use different hardware resources

2. Autobahn Consensus Protocol (Upcoming)

Future Features: The Autobahn consensus protocol described here represents upcoming enhancements. The current system uses optimized Tendermint consensus (Twin Turbo).

The upcoming Sei Giga will employ Autobahn, a Byzantine Fault Tolerant (BFT) consensus protocol designed for high performance blockchain networks. Unlike traditional single-proposer systems, Autobahn will enable multiple validators to propose blocks simultaneously, targeting significant throughput improvements while maintaining security guarantees.

Autobahn Consensus Architecture

Data Dissemination Layer (Lanes)

• Lane $\ell_1$: ${Prop}_1$, ${Prop}_2$, ${Prop}_3$, $Tip$
• Lane $\ell_2$: ${Prop}_1$, ${Prop}_2$, $Tip$, …
• Lane $\ell_n$: ${Prop}_1$, ${Prop}_2$, ${Prop}_3$, $Tip$

Each validator maintains independent lane.

Consensus Layer (Cut Formation)

$Cut = [{Tip}_1, {Tip}_2, ..., {Tip}_n]$

Periodic ordering of lane tips.

1. Prepare Phase — Leader collects tips, forms Cut
2. Fast Path ($n$ votes) — Immediate commit if all agree
3. Slow Path ($2f+1$ votes) — Additional round if needed

Global ordering through BFT agreement.

Protocol Properties

Network Model

$n = 3f + 1$ replicas

Safety

Unconditional

Liveness

Eventual synchrony

The protocol operates through two complementary layers:

Data Dissemination Layer (Lanes):

• Each validator maintains an independent lane for proposing transaction batches
• Three-step certification process: Propose → Vote → Proof of Availability (PoA)
• Chained proposals ensure availability of historical data

Consensus Layer (Cut of Tips):

• Periodic ordering of latest certified tips from all lanes
• Two-phase BFT agreement with fast and slow paths
• Pipelined slots for minimal latency

Enabling Autobahn on a Node

Node Operators: Autobahn (GigaRouter) can now be enabled experimentally on a node by pointing the autobahn-config-file field in config.toml to a JSON configuration file. Leave the field empty to keep Autobahn disabled.

To enable Autobahn, set the following in your node’s config.toml:

# Path to a JSON file containing the Autobahn (GigaRouter) configuration.
# Leave empty to disable Autobahn.
autobahn-config-file = "/path/to/autobahn.json"

The node must be a committee member: its own validator public key and node public key must appear in the validators list of the referenced config file.

Remote signers are not supported: When autobahn-config-file is set, the node fails to start if priv-validator.laddr is also configured. A local validator key is required — non-validator (observer) nodes are not yet supported.

Autobahn JSON Configuration Schema

The file referenced by autobahn-config-file is a JSON document with the following fields:

Field	Type	Description
validators	array	The committee. Each entry is an object with validator_key (Autobahn validator public key), node_key (p2p node public key), and address (network host:port).
max_gas_per_block	number	Maximum gas allowed per block. Must be greater than 0.
max_txs_per_block	number	Maximum transactions per block. Must be greater than 0.
max_txs_per_second	number | null	Optional cap on transactions per second. Omit or set null for no limit.
block_interval	duration	Target interval between blocks. Must be greater than 0.
allow_empty_blocks	boolean	Whether empty blocks may be produced.
view_timeout	duration	Consensus view timeout. Must be greater than 0.
persistent_state_dir	string | null	Directory for persisting the Autobahn consensus and data-layer WALs across restarts, so both layers survive process restarts (they share this on-disk root and write to distinct subdirectories under it). Relative paths are resolved against the node’s --home directory at load time; absolute paths are used as-is. Set to null (or generate with an empty --persistent-state-dir) to disable persistence and run in-memory only.
dial_interval	duration	Interval at which peers are dialed. Must be greater than 0.

Example configuration file:

{
  "validators": [
    {
      "validator_key": "ed25519:public:...",
      "node_key": "node:ed25519:public:...",
      "address": "peer1.example.com:26660"
    }
  ],
  "max_gas_per_block": 50000000,
  "max_txs_per_block": 5000,
  "max_txs_per_second": 1000,
  "mempool_size": 20000,
  "block_interval": "200ms",
  "allow_empty_blocks": true,
  "view_timeout": "1.5s",
  "persistent_state_dir": "/tmp/autobahn-state",
  "dial_interval": "10s"
}

The node validates this file on startup and refuses to start if any required field is missing, if the validators list is empty, if a validator_key or node_key is duplicated, or if the node’s own validator and node keys are not present as a matching entry in the validators list.

Generating the config with gen-autobahn-config

Rather than hand-authoring the JSON file, you can generate it from per-node pubkey files using the seid tendermint gen-autobahn-config command:

seid tendermint gen-autobahn-config [node-dirs...] --output <path>

The command reads four files from each node directory passed as an argument and assembles one validators entry per directory:

• validator_pubkey.txt — the Autobahn validator public key, in validator:<pubkey> format
• node_pubkey.txt — the p2p node public key, in node:ed25519:public:<hex> format
• autobahn_address.txt — the node’s network address in host:port format
• evmrpc_url.txt — the node’s EVM RPC HTTP URL (for example http://<host>:8545), used to proxy EVM requests to the validator that owns the sender’s shard

The --output (or -o) flag is required and specifies where the generated JSON config is written. The generated file uses default consensus parameters (for example, a 400ms block interval and a 1.5s view timeout), which you can adjust afterward if needed.

The validator_pubkey.txt and node_pubkey.txt files are written automatically alongside the validator private key and node key whenever those keys are saved (for example, during seid init), so each node’s config directory already contains the pubkey files needed for generation. You still need to create the autobahn_address.txt file with the node’s reachable host:port address.

Example generating a config across three node directories:

seid tendermint gen-autobahn-config \
  build/generated/node_0 \
  build/generated/node_1 \
  build/generated/node_2 \
  --output ~/.sei/config/autobahn.json

Once generated, point autobahn-config-file in config.toml at the resulting file to enable Autobahn.

Reactor changes when Autobahn is enabled

Behavior change: When a node runs with autobahn-config-file set, several standard reactors are disabled because they are incompatible with Autobahn’s block production model.

Enabling Autobahn changes how the node builds and synchronizes blocks:

• Mempool gossip reactor disabled: Transaction gossip across the standard mempool reactor is turned off. The shared TxMempool still accepts and stores transactions, but they are no longer broadcast peer-to-peer through the legacy mempool channel.
• Consensus reactor disabled: The Tendermint consensus reactor is not started; block ordering is handled entirely by the Autobahn (GigaRouter) protocol.
• State sync and block sync disabled: Both the statesync and blocksync reactors are skipped, so a node cannot catch up through those paths while Autobahn is active.
• Direct reaping from the shared mempool: The block producer no longer uses a separate producer mempool channel. Instead, it reaps transactions directly from the shared TxMempool when assembling each block’s payload.

Because of these changes, an Autobahn-enabled node relies solely on the Autobahn data-dissemination and consensus layers for ordering and propagation, rather than the legacy gossip, consensus, and sync reactors.

Block limits: Autobahn blocks are bounded by hard on-chain limits — at most 2000 transactions per block and roughly 2 MB of total transaction bytes — in addition to the max_gas_per_block and max_txs_per_block values in the config file. These limits are enforced while the payload is built.

3. Advanced Parallel Execution

The parallel execution architecture extends beyond current OCC capabilities to include:

Parallel Execution Pipeline

Stage 1

Transaction Parsing

Parallel decode

Stage 2

Dependency Analysis

Conflict prediction

Stage 3

Parallel Execution

Multi-core OCC

Stage 4

State Commit

Batch writes

Conflict Detection

• Read/Write set tracking
• Optimistic execution
• Automatic re-execution on conflict
• Preserves deterministic ordering

Performance Stats

• ~65% of ETH txs parallelizable
• Linear scaling with cores
• Minimal conflict overhead
• Zero-copy transaction handling

Key innovations in the execution model:

• Flat encoding format: Length-prefixed layout for fast, zero-copy decoding
• Predictive conflict analysis: ML-based prediction of transaction dependencies
• Semantic understanding: Special handling for common patterns (ERC-20 transfers)
• Adaptive parallelism: Dynamic adjustment based on conflict rates

Storage Architecture Evolution

Beyond the current SeiDB capabilities, the Sei Giga architecture includes advanced storage innovations:

Hybrid Storage Architecture

Hot Storage Tier

• Recent Blocks — High-speed NVMe SSDs
• Active State — Memory-mapped files
• Access Pattern — Sub-ms latency

Warm Storage Tier

• Recent History — Standard SSDs
• Compressed State — LZ4 compression
• Access Pattern — 1-10ms latency

Cold Storage Tier

• Historical Data — Distributed storage
• Columnar Format — Analytics optimized
• Access Pattern — Batch queries

Cryptographic Layer

Flat KV Store

LSM-tree based

Cryptographic Accumulators

Compact proofs

Write-Ahead Log

Durability guarantee

Economic Model

Sei operates with a native SEI token that serves multiple functions within the ecosystem:

Token Distribution

• Total Supply: 10,000,000,000 (10 billion) SEI
• Initial Distribution: Allocated across ecosystem participants, validators, and development

Token Utility

1. Gas Fees: All transactions require SEI for execution
2. Staking: Validators and delegators stake SEI to secure the network
3. Governance: SEI holders participate in protocol governance
4. Rewards: Block rewards and fee distribution to validators

Staking Mechanics

Staking & Validation

Validators

• Self-Stake Requirement — Minimum SEI to operate
• Commission Rate — Set by validator
• Responsibilities — Consensus & execution

Delegators

• Delegation — Stake with chosen validators
• Rewards — Proportional to stake
• Unbonding — 21-day period

Slashing Conditions

Liveness Failures

Penalties for downtime

Safety Violations

Severe penalties for double-signing

Developer Experience

Sei maintains full EVM compatibility while providing enhanced capabilities:

Standard EVM Features

• Complete support for Solidity and Vyper
• Standard JSON-RPC endpoints
• Compatible with existing tools (Hardhat, Foundry, Remix)
• Familiar development workflow

Enhanced Capabilities

• Sub-second transaction finality
• Predictable gas costs
• High throughput for complex applications
• Advanced storage access patterns

Implementation Status

Current & Upcoming Features

Current Implementation — Live on Mainnet

Twin Turbo Consensus

~400ms blocks

Parallel Execution

Multi-core processing

SeiDB Storage

Optimized state access

Upcoming Features — In Development

Autobahn Consensus

Multi-proposer protocol

5 Gigagas Throughput

Performance target

Advanced Optimizations

Enhanced execution

Learn More

Explore the technical components that make Sei’s performance possible:

• Twin Turbo Consensus →
• Parallelization Engine →
• SeiDB Storage →
• Developer Guide →