I’ve been watching layer-one networks chase higher throughput for years, and every so often a project actually changes the plumbing instead of just talking about it. Sei just did that. The first phase of its Eidos storage rebuild is already live on mainnet, and the stated target is still the same ambitious number that made people sit up when the Giga whitepaper dropped: 200,000 transactions per second. That is not a marketing flourish. It is the concrete goal the team is engineering toward, and storage was the quiet bottleneck they decided to fix first.
Why Storage Became the Real Limit
Most conversations about blockchain speed focus on consensus or execution engines. Those pieces matter, of course. But when a network starts processing tens or hundreds of thousands of transactions every second, the database underneath has to keep up. If every state change forces a node to recalculate a long chain of hashes, the whole system slows down no matter how fast the other layers become.
Traditional Merkle trees work that way. Change one value and the node has to walk back up the tree, updating every parent hash until it reaches the root. As the state grows, those updates get heavier. Sei’s engineers looked at that pattern and decided it would not survive the load planned for Giga. Eidos is their answer: a complete rebuild of how the chain stores and verifies data.
In my view, this is the unglamorous work that actually decides whether a high-TPS claim is real. Consensus can be elegant and execution can be parallel, but if the storage layer chokes, none of it reaches users. Sei treated that risk seriously enough to start the migration while the chain stays online.
The Three-Part Giga Architecture
Eidos does not stand alone. It is the storage leg of a broader redesign that also includes Autobahn for consensus and Ares for transaction execution. Together the three pieces form the Giga upgrade path. The team has been clear that all three layers need to move in step if the network is going to hit the numbers in the whitepaper: 200,000 TPS, roughly 5 gigagas of throughput, and finality under 400 milliseconds.
At those speeds the chain will write hundreds of thousands of database entries every second. Faster execution alone would not help if the storage system could not absorb the writes and still serve reads for live traffic. That is the practical pressure behind Eidos.
Consensus. Execution. Storage. The Giga Upgrade rebuilds all three layers of the chain. Eidos is the storage rebuild, and its first phase is live.
The first components reached mainnet through the v6.6 release. EVM state has begun moving into its own dedicated database. Later stages will bring FlatKV, LtHash, a new receipt store, and off-node archival systems. The migration is designed to run while the chain stays fully operational, with old and new storage systems working side by side.
How FlatKV Changes the Write Path
The heart of the redesign is a shift away from Merkle trees for EVM state. FlatKV is a flat key-value store. When a value changes, the node performs a single write instead of recalculating a path of hashes. That sounds simple, but the difference compounds quickly at scale.
Verification still needs to happen, of course. That is where LtHash, or lattice hashing, comes in. Instead of maintaining a tree, the system keeps a running fingerprint of the entire state. When a value updates, the node subtracts the contribution of the old value and adds the contribution of the new one. The work stays constant no matter how large the state becomes.
I find that design choice particularly elegant. Most storage systems pay an increasing cost as data grows. LtHash keeps the cost flat. For a network that expects to write state changes at extreme rates, that property is not a nice-to-have. It is a requirement.
The technical change is tied directly to the performance targets. At 200,000 transactions per second the storage layer has to absorb writes without becoming the slowest part of the pipeline. FlatKV and LtHash are engineered for exactly that scenario.
Separating EVM State from Everything Else
Another practical improvement is the isolation of EVM state. Previously, EVM data shared a database with other information held by Sei nodes. That shared arrangement meant historical queries and live transaction processing competed for the same resources. Non-EVM modules also paid a tax every time the EVM state changed.
The new architecture gives EVM state its own dedicated store. Live execution no longer fights with archival reads. Modules that do not touch EVM data avoid unnecessary database work. The split began landing on mainnet with the v6.6 upgrade in August.
Alongside the separation, Sei rebuilt the pruning path that removes data nodes no longer need in active storage. In testing and early operation the cleanup process dropped from a range of eight to eighteen minutes down to roughly five minutes. Nodes that previously lagged hundreds of blocks behind the tip now stay within about sixty blocks. That is a noticeable operational improvement for anyone running infrastructure.
LittDB for Blocks and Receipts
Blocks and transaction receipts have different access patterns from account and contract state. They are written once, read repeatedly, and eventually archived. Treating them the same way as mutable state is inefficient. Sei therefore introduced a separate storage engine called LittDB for this class of data.
Internal benchmarks showed LittDB sustaining write throughput above one gigabyte per second while handling around 55,000 point reads per second. A dedicated receipt store managed more than 150,000 writes per second during multi-hour tests that included garbage collection. The team is careful to note that these figures measure the storage engine itself and should not be confused with blockchain transaction throughput. Still, the numbers indicate the hardware can keep up with the volume Giga expects.
Having a purpose-built engine for write-once, read-many data is one of those details that rarely makes headlines yet matters a great deal once the chain is under real load.
Moving History Off Active Nodes
As networks grow, the amount of historical data becomes a practical problem. Keeping every past state on every active node forces operators to buy faster and more expensive hardware just to stay current. Eidos changes that expectation.
Frequently accessed state and recent chain history stay on fast local storage. Older records move to archival systems designed for capacity rather than speed. Explorers, indexers, and users who need to audit historical transactions can still retrieve the data. Active nodes simply stop carrying the full weight of the past.
This separation reduces the chance that historical queries will steal resources needed for live transaction processing. It also keeps hardware requirements more predictable as throughput rises. In my experience watching other chains scale, this is one of the more practical long-term decisions a team can make.
Migration Without Downtime
Perhaps the most carefully engineered part of the rollout is the decision to keep the chain online the entire time. Existing and replacement storage systems operate in parallel while data moves in controlled batches from block to block. Governance controls the pace, and a documented rollback path exists if anything goes wrong.
Before the mainnet deployment, shadow nodes replayed live traffic against the new storage systems while integrity hashes were checked continuously. Testing showed that block times remained largely unchanged even while migration processes ran in the background. That is the kind of result that gives operators confidence.
Users and application developers do not need to take any action. Balances, smart contracts, historical records, and existing RPC endpoints stay available. Node operators received a migration guide covering configuration flags and the rollback procedure. The approach is conservative and, from what I can see, well thought through.
Context from Earlier Ecosystem Moves
The storage work sits on top of earlier efforts to expand access to Sei’s EVM environment. Native wallet support arrived in 2025, making it straightforward for users to interact with applications, swap assets, and bridge tokens. At that point the network was already processing more than 4.2 million daily transactions and reported more than 11 million monthly active users.
A distribution agreement later that year aimed to pre-install a Sei wallet on new smartphones sold in selected markets outside mainland China and the United States. Plans also included support for stablecoin payments. Those distribution steps matter because high throughput only becomes valuable if people can actually reach the applications.
Eidos is the third major storage rebuild the network has undertaken. The first replaced the original Cosmos storage architecture with SeiDB. The second introduced the state-store separation now landing on mainnet. FlatKV, LittDB, and the archival layer form the next stage.
What the Numbers Actually Mean
Two hundred thousand transactions per second is an aggressive target. It is also a concrete engineering goal rather than a vague aspiration. The whitepaper laid out the design parameters: high throughput, multi-gigagas execution capacity, and sub-400-millisecond finality. Storage had to be rebuilt to match those parameters, or the other layers would have been limited by the database.
I have seen projects announce ambitious TPS numbers and then quietly lower them when the storage layer could not keep up. Sei’s decision to treat storage as a first-class problem, and to migrate it without taking the chain offline, suggests they are serious about the target. Whether the final system reaches exactly 200,000 TPS will depend on many factors still ahead. The foundation being laid now is the part that was most likely to fail under load.
The phased approach also reduces risk. Shipping FlatKV and LtHash later, after the EVM state separation and pruning improvements are already live, lets the team validate each piece under real conditions before adding the next. That incremental style is usually smarter than a single big-bang upgrade.
Practical Implications for Operators
Node operators are the ones who will feel the changes most directly. The migration guide covers the configuration flags needed to participate. The dual-storage period means extra disk and memory usage for a while, but the design keeps the chain progressive even if individual nodes lag slightly.
The improved pruning path should make it easier to stay close to the tip without heroic hardware. Moving older history off active nodes will further reduce the storage pressure that tends to creep upward over time. For operators who have watched their disk requirements grow relentlessly on other chains, this direction is welcome.
Rollback capability is another practical detail. Knowing that a problematic stage can be reversed without a hard fork or extended downtime lowers the cost of moving forward. That safety net is part of what makes a phased rollout viable.
Looking Ahead at the Remaining Stages
The components still to come are the ones that complete the performance picture. FlatKV and LtHash will change how state updates are written and verified. The new receipt store and off-node archival systems will handle the data that does not need to live on every active node. Each of those pieces has its own release window and will be introduced under the same governance-controlled, dual-operation model.
Once the full storage stack is in place, attention will shift more heavily to the Autobahn consensus work and the Ares execution layer. The three pieces need to arrive in a coherent sequence if the network is to deliver the full Giga profile. Storage is simply the first of the three to begin landing on mainnet in a substantial way.
I expect the coming months will bring more detailed performance numbers from the live migration and from the subsequent stages. Those measurements will matter more than any whitepaper claim. Real traffic under the new storage system is the only way to know whether the constant-time update path and the dedicated engines behave as designed.
Why This Kind of Work Rarely Makes Headlines
Most crypto coverage prefers flashy product launches or token price movements. Storage architecture changes do not generate the same excitement. Yet the quiet work often determines whether a network can actually deliver the experience its marketing describes. Sei’s decision to treat storage as a core part of the Giga redesign, and to ship the first pieces while keeping the chain live, is the sort of engineering discipline that tends to pay off later.
The team has already completed two earlier storage rebuilds. That history suggests they understand how painful these migrations can be and have learned from previous rounds. Eidos is larger in scope, but the same careful, phased style is visible in the rollout plan.
For developers building on the network, the practical message is simple: nothing breaks for users or applications during the migration. RPC endpoints remain available. State remains consistent. The underlying database is being swapped while the lights stay on. That is a harder engineering problem than it sounds, and it appears to be progressing as planned.
A Few Open Questions Worth Watching
Every major infrastructure change leaves a few questions that only live operation can answer. How will the dual-storage period affect disk and memory usage on typical validator hardware? Will the constant-time LtHash updates hold their performance characteristics once the state size grows into the ranges expected under full Giga load? How quickly can older history be moved to archival systems without creating temporary pressure on active nodes?
These are the kinds of details that will surface in operator reports and in the next set of technical updates. I will be watching for those measurements more than for any new headline number. The real test of Eidos is not the first announcement. It is whether the storage layer continues to keep pace once the other two legs of the Giga architecture arrive.
For now the first phase is live, the migration is underway without downtime, and the design goals remain clear. Storage is no longer the quiet constraint it once was. That alone is a meaningful step for a network aiming at extreme throughput.
Putting the Pieces Together
Sei’s Eidos upgrade is less about a single flashy feature and more about removing a structural limit that would have capped everything else. By moving EVM state into its own database, introducing a flat key-value store with lattice hashing, building a purpose-built engine for blocks and receipts, and planning to shift older history off active nodes, the team is rebuilding the foundation rather than papering over it.
The work is happening in stages, under governance control, with a rollback path, and while the chain continues to process transactions. Users and developers can keep building without interruption. Operators have clear documentation. The performance targets remain ambitious, but the storage layer is no longer the most likely point of failure.
That combination of ambition and careful execution is what makes the current phase worth following. The next releases will show whether FlatKV and LtHash deliver the constant-time behavior under real load, and whether the full Giga stack can approach the numbers outlined in the whitepaper. For the moment the first pieces are already running, and the network is still online. That is a solid place to begin.
In the broader landscape of layer-one development, few teams have treated storage with this level of deliberate redesign. Most focus on consensus or parallel execution and hope the database keeps up. Sei decided the database would not keep up, so they rebuilt it. The early results from the v6.6 release and the ongoing migration suggest the approach is working as intended. The coming stages will tell us how far the redesign can go.
Until then, the practical takeaway is straightforward. A major storage overhaul is underway on a live chain that already carries meaningful traffic. The goal is still 200,000 transactions per second. The first tools needed to reach that goal are now in production. The rest of the path is being built in the open, one controlled stage at a time.
