Sei has begun rolling out its Eidos storage upgrade, rebuilding how the layer-1 network stores and verifies on-chain data as its Giga roadmap targets throughput of 200,000 transactions per second.
Summary
- Sei has begun the phased rollout of Eidos through its v6.6 mainnet upgrade.
- Eidos is rebuilding the network’s storage architecture as Giga targets 200,000 TPS.
- EVM state is being separated into a dedicated database, while FlatKV and LtHash are planned for later stages.
- The migration is designed to run while Sei remains online, with existing and new storage systems operating alongside each other.
Sei said in an Aug. 12 technical update that Eidos is designed to remove storage constraints that could prevent the network’s execution layer from operating at the speeds planned under Giga. The upgrade is the storage component of a three-part architecture overhaul that also includes Autobahn for consensus and Ares for transaction execution.
The first Eidos components have already reached mainnet through Sei v6.6, though the full storage system is being introduced in stages. EVM state has started moving into a dedicated database, while FlatKV, LtHash, new receipt storage and off-node archival systems are scheduled for subsequent releases.
Sei Eidos upgrade changes how state is stored
At the center of Eidos is a change to the way Sei plans to maintain and verify Ethereum Virtual Machine state.
Sei said traditional Merkle trees require nodes to recalculate multiple hashes when a value changes because each update alters the chain of hashes leading to the tree’s root. As the amount of stored data increases, individual state changes can therefore require additional database work.
Eidos is set to replace that structure for EVM state with FlatKV, a flat key-value storage system where an individual state change requires a single write. Verification will be handled using LtHash, or lattice hashing, which maintains a running fingerprint of the state.
Under the design described by Sei, LtHash can update that fingerprint in constant time when state changes. Instead of recalculating a path of hashes through a Merkle tree, a node removes the contribution of the old value and adds the new one, leaving the amount of work per update unchanged as the state expands.
The technical change is tied directly to the performance targets outlined for Giga. As crypto.news reported in May 2025, Sei Labs released its Giga whitepaper with a design targeting 200,000 transactions per second, 5 gigagas of throughput and finality below 400 milliseconds.
At that throughput, Sei said the network would also have to write hundreds of thousands of database entries every second. Faster transaction execution would therefore provide limited benefit if the storage layer could not process state changes and transaction history at a comparable rate.
EVM data is moving into a separate database
Another part of Eidos separates EVM state from other data handled by Sei nodes.
Before the change, Sei said EVM state shared a database with other information on the chain. The new architecture gives EVM state its own dedicated store, preventing historical queries from competing directly with live transaction processing and reducing database work imposed on non-EVM modules.
The split started reaching mainnet in the v6.6 release during August. Sei also introduced a rebuilt pruning path for removing data that nodes no longer need to keep in active storage.
According to the network, the pruning changes reduced one cleanup process from between eight and 18 minutes to roughly five minutes during testing and operation. Nodes that could previously fall hundreds of blocks behind the chain tip remained within about 60 blocks after the change, Sei said.
Blocks and transaction receipts are also being assigned a separate storage engine called LittDB. Sei described blocks and receipts as data that is written once, repeatedly read, and eventually archived, making their storage requirements different from frequently updated account and contract state.
Internal benchmarks cited by Sei put LittDB write throughput above one gigabyte per second while handling about 55,000 point reads per second. A new receipt store sustained more than 150,000 writes per second during multi-hour benchmark tests that included garbage collection. Sei cautioned that the figure measures the storage engine and should not be treated as blockchain transaction throughput.
Older history will move away from active nodes
Eidos also changes how much historical information individual nodes are expected to keep locally.
Sei said frequently accessed state and recent chain history will remain on fast local storage, while older historical records will move to archival systems built for capacity. Explorers, indexers and users auditing historical transactions will still be able to retrieve the archived information, according to the network.
Reducing the amount of old data kept on active nodes is intended to prevent historical queries from consuming resources needed for current transactions. Sei said rising storage requirements can otherwise force operators to use faster and more expensive hardware as network throughput increases.
The infrastructure work follows earlier efforts to increase access to Sei’s EVM ecosystem. MetaMask added native Sei support in August 2025, allowing users to access Sei-based applications, swap assets and bridge tokens directly through the wallet. At the time, Sei was processing more than 4.2 million daily transactions and had more than 11 million monthly active users, according to figures cited in the report.
A separate distribution agreement announced in December 2025 called for Xiaomi to pre-install a Sei wallet on new smartphones sold outside mainland China and the United States. The companies also planned support for stablecoin payments using assets such as USDC, with initial payment deployments planned for Hong Kong and the European Union.
Eidos migration runs while Sei remains online
For node operators, Sei is carrying out the storage migration without stopping the blockchain.
The network said existing and replacement storage systems will operate alongside one another while data moves in batches from block to block. The rollout is controlled through governance and has been designed with a rollback process if problems emerge.
Ahead of deployment, shadow nodes replayed mainnet traffic against the new storage systems while integrity hashes were continuously checked, according to Sei. Testing showed block times remained largely unchanged while migration processes operated in the background.
Eidos is the third storage rebuild undertaken by Sei. The network previously replaced its original Cosmos storage architecture with SeiDB, followed by the state-store separation now being introduced on mainnet. FlatKV, LittDB and the off-node archival system will form the next stage as they arrive through later releases.
Users and application developers do not need to take action during the migration, according to Sei, with balances, smart contracts, historical records and existing RPC endpoints remaining available. Node operators have been given a migration guide covering configuration flags and the documented rollback process for the new storage system.
