Sei Network's Giga upgrade is not a single software patch. It is a full architectural overhaul of three core parts of the blockchain: consensus, execution and storage, each rebuilt in parallel with the network continuing to run.
Three Tracks, One Goal
Giga is structured around three upgrade tracks. The first is consensus, where a protocol called Autobahn replaces the single-proposer model. Autobahn is a multi-proposer consensus protocol. Traditional blockchains rely on a single block proposer at a time, creating a bottleneck. Autobahn lets multiple validators propose blocks simultaneously, which is how you get from thousands of transactions per second toward hundreds of thousands.
The second track is execution, handled by the Ares upgrade. Ares is a rebuilt execution engine that becomes the default path for running transactions on mainnet.
The third track is storage, which is where Eidos comes in. Every transaction processed by a blockchain must be recorded. If the database cannot write data as fast as the network executes transactions, raw throughput gains become meaningless. Eidos upgrades Sei's storage layer, and both Ares and Eidos need to keep pace with the 200,000 TPS that Sei Giga is targeting.
Why Storage Is the Hard Part
Eidos retires the Merkle tree for Sei's EVM state. Its replacement, FlatKV, keeps state in a flat key-value layout where one change is one write. A lattice hash (LtHash) maintains a running fingerprint of the entire state that updates in constant time per change, without cascading recomputation.
Eidos also separates live EVM state from other blockchain data entirely. This decouples EVM historical state from the Cosmos SDK state into an independent database, eliminating disk I/O bottlenecks for real-time transactions. Separately, LittDB-backed storage handles blocks and receipts. These records are written once but queried repeatedly, making them a distinct workload from constantly changing chain state. Older historical data will eventually migrate off active nodes into archival storage.
Crucially, the migration itself is designed to avoid downtime. Instead of halting the network and replacing the entire database at once, Eidos is built to migrate storage while Sei continues producing blocks, with the old and new systems running side by side, data moved in batches and integrity checks run throughout.
Executed via governance proposal in early August 2026, v6.6 introduced mainnet deployments of two foundational components of the broader Sei Giga plan: the Ares execution engine and the Eidos storage engine. The pruning fix that shipped alongside Eidos is already measurable for operators, reducing a cleanup pass that used to take 8 to 18 minutes down to about five, and keeping nodes within 60 blocks of the chain tip where they used to drift hundreds behind.
The larger parts of Eidos, including FlatKV with its lattice hash, the LittDB-backed receipt store and off-node archival storage, will arrive in subsequent releases.
The multi-phase Giga plan targets sub-250ms block finality and industrial-grade throughput for decentralised finance, with 200,000 TPS as the headline goal. Reaching that speed requires more than a faster transaction engine. It requires a storage system capable of keeping up. That is what Eidos is trying to build.
Sources:
Sei Labs: The Eidos Upgrade, official blog
Sei Labs: Ares and Eidos go live in Sei 6.6, official blog
Crypto Briefing: Sei unveils Giga upgrade roadmap