Sei Launches Eidos Storage Overhaul to Unlock 200,000 TPS Capacity

The Storage Bottleneck No One Talks About

According to a technical update published on August 12, the first components already reached mainnet through the v6.6 release, with the broader system rolling out incrementally. For engineers evaluating high-throughput chains, the move highlights a problem that often gets buried under consensus and execution benchmarks: at extreme TPS, the storage layer becomes the binding constraint.

Why Merkle Trees Break Down at Scale

The core of Eidos is a structural replacement for how Sei maintains and verifies EVM state. Traditional Merkle trees require nodes to recalculate a chain of hashes leading to the root every time a single value changes. As state grows, each update imposes additional database work — a cost that scales with the depth of the tree. At the throughput levels Giga targets, Sei would need to write hundreds of thousands of database entries per second. Faster execution means little if the storage layer cannot keep pace.

Eidos introduces two key primitives to address this. FlatKV replaces the tree structure with a flat key-value store where an individual state change requires a single write — no hash chain recalculation. LtHash (lattice hashing) handles verification by maintaining a running fingerprint of the state. Instead of walking a Merkle path, a node removes the contribution of the old value and adds the new one, keeping the work per update constant regardless of state size. In practice, this means storage latency should not degrade as the EVM state expands — a trade-off that favors predictable performance over the incremental integrity guarantees of traditional trees.

Decoupling EVM State and Pruning Wins

Another architectural decision in Eidos is the separation of EVM state from other on-chain data. Previously, Sei nodes stored EVM state in the same database as non-EVM information, meaning historical queries could compete directly with live transaction processing. The new dedicated store isolates these workloads, reducing contention at the database level. This split began shipping in v6.6 during August.

Sei also rebuilt its pruning path for removing data nodes no longer need in active storage. During testing, one cleanup process dropped from between eight and 18 minutes to roughly five minutes. Nodes that previously fell hundreds of blocks behind the chain tip now stay within about 60 blocks — a meaningful improvement for operators running archival or RPC infrastructure.

What to Watch

Eidos is one leg of a three-part architecture overhaul: Autobahn handles consensus, Ares targets transaction execution, and Eidos covers storage. The Giga whitepaper, released in May 2025, sets the combined target at 200,000 TPS, five gigagas of throughput, and sub-400-millisecond finality. None of those numbers matter if any single layer bottlenecks the others.

For developers building on Sei or benchmarking L1/L2 architectures, the practical takeaway is straightforward: storage design is not an afterthought. FlatKV and LtHash represent a deliberate bet that constant-time state updates outweigh the well-understood security properties of Merkle proofs. Whether that trade-off holds under adversarial conditions and sustained load is something the staged rollout should clarify — watch for performance data as subsequent Eidos components hit mainnet.