Sign in Subscribe

The Eidos Upgrade: replacing Sei’s storage database while the chain is running

The Eidos Upgrade: replacing Sei’s storage database while the chain is running

TL;DR: Every blockchain node has two jobs: compute what happens next on the chain, and store what has already happened. Storage is a critical bottleneck for all blockchains as they attempt to scale. If storage can't keep pace with the rate at which new transactions are executing, huge problems can occur. Eidos is the upgrade that will take Sei’s storage layer to Giga speed.

What is Sei's Giga Upgrade?

Giga is the series of upgrades designed to dramatically improve the Sei blockchain, making it much faster and giving it next-generation features, to make it the optimal onchain environment for trading.

Giga is composed of three tracks of upgrades, one for each layer of the chain. A series of consensus upgrades, beginning with Autobahn, will rebuild how validators agree on what’s true. The Ares Upgrade rebuilds execution, the part that actually runs transactions. Eidos rebuilds storage, the critical part of the chain that stores all the transactions that have happened and allows users and apps to query this data.

Every transaction that a blockchain executes has to be written down, and if the notebook can’t keep up with the pen, the pen’s speed is irrelevant. A chain that executes at 5 gigagas per second while writing to a database designed for an earlier era is a sports car on bicycle wheels.

Eidos exists to fix that. It introduces a new database structure, and implements it onto the chain live, while the blockchain keeps running.

Understanding blockchain storage

A blockchain stores multiple things. First, the live state of the network: every account balance, every deployed contract, every value those contracts keep in their storage. Secondly, the historical state: every block ever produced, every transaction inside those blocks, and every receipt recording what each transaction did.

This storage is essential for every aspect of using a blockchain. When you check a balance in your wallet, a node looks it up in state. When a trading app draws a price chart or a block explorer shows last week’s transfers, nodes are reading history.

Each transaction changes some state and appends to history, so a chain processing 200,000 transactions per second is also writing hundreds of thousands of database entries per second, every second, forever.

When a blockchain’s storage can’t keep pace with execution, often the only way to survive is to throw money at the problem. Larger, faster, and more expensive disks can compensate for a slow data layer. But as throughput grows and hardware requirements rise, the cost of running a node swells until most operators can’t afford to run them. Queries about last month slow down the processing of live transactions. Eventually the execution layer, however fast, sits idle waiting for the database to catch up.

Why Sei Giga needs better data validation

A blockchain database can’t just store data; it has to be able to verify the data hasn’t been tampered with. The classic tool for this is a Merkle tree: every piece of state gets hashed, hashes get paired and hashed again, and again, until a single root hash fingerprints the entire state of the chain. Anyone can check a value against that root and know it’s genuine.

Because the values are chained together in a tree, updating one account means recomputing every hash on the path from that account up to the root, and each of those recomputations is another disk write. Even worse, the more data stored by the chain, the more expensive each individual update becomes. Because of this, at 200,000 TPS, Merkle trees stop being feasible.

Eidos retires the Merkle tree for Sei’s EVM state. Its replacement, a store called 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. The network keeps its ability to verify everything.

Instead of arranging every value in a tree and hashing a path to the top, the node keeps one fingerprint that individual changes can be added to or subtracted from directly. Update a balance and the node subtracts the old value’s contribution and adds the new one, a fixed amount of work no matter how large the state grows.

What else changes under the hood

Removing the Merkle tree is the core architectural move, but Eidos is a rebuild of the whole storage stack.

Live state gets its own database

Today, EVM state shares a single database with everything else on the chain. Under Eidos it moves into its own dedicated store. Reads of history stop competing with live transaction processing, and the chain’s non-EVM modules stop paying write costs for EVM data they never touch. The EVM state split began rolling out in v6.6.

Each workload gets the right engine

Every transaction onchain produces a receipt: a record of what happened, what it cost, and which events it emitted. Each time a wallet shows the confirmation checkmark, an app verifies your swap landed, or a dashboard tallies yesterday’s volume, something is reading receipts. At Giga’s target throughput, Sei would produce 200,000 of them per second.

Blocks and receipts have a peculiar shape as data: written once, never updated, read constantly, and eventually archived. Sei’s new block and receipt stores run on LittDB, an open-source embedded database originally developed by a Sei Labs engineer for exactly this write-once pattern, now integrated into Sei’s node software. LittDB has been clocked at over a gigabyte per second of write throughput while serving roughly 55,000 point reads per second at the same time, and the new receipt store sustained more than 150,000 writes per second, flat, across multi-hour benchmark runs that included garbage collection. That number is a benchmark of the storage engine itself, not a chain TPS figure, so it isn’t comparable to Giga’s 200,000 TPS target.

Old history leaves the node

While the state and recent history a node actually touches stay local, on the fastest storage, older history moves off the node entirely, into archival storage built for capacity rather than speed. Full history stays available to anyone who asks: explorers, indexers, and anyone auditing the chain’s past read from the archive, while the nodes doing real-time work carry only what real-time work needs.

Upgrading storage while the chain stays live

Sei already has a live database which holds the entire live state of the network, and the chain on top of it produces a block roughly every 400 milliseconds, around the clock.

The easiest option would be to halt the chain, snapshot everything, migrate, and relaunch. Or ask every node operator to throw away their data and rebuild from scratch. Both approaches are common, and respected networks have used them.

Eidos takes the harder route: the migration runs inside the node while the chain keeps producing blocks. Data moves across in small batches, block by block, with the old and new stores running side by side until the new one has proven itself, and the whole rollout is switched on by governance and reversible by design. It’s also checked at every step: shadow nodes replayed real mainnet traffic against the new stores before rollout, integrity hashes are audited continuously, and in testing, block times stayed essentially unchanged while the migration ran underneath.

The first phase of Eidos reached Sei mainnet with the v6.6 release in August 2026. EVM state began moving into its own database, and a rebuilt pruning path shipped alongside it. That pruning fix 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 the Eidos upgrade, such as FlatKV with its lattice hash, the LittDB-backed receipt store, the off-node archive, will arrive in subsequent releases.

What users need to know

Users and app developers don't have to take any actions. Balances, contracts, and history carry over untouched. Existing RPC endpoints can be used as normal.

If you run a node, the migration guide for RPC operators is already public in the sei-chain repository, with the config flags and the rollback path documented. Longer-term, node operators will be able to run leaner machines. This has long term benefits for the chain, as it will become cheaper to become a Sei node operator.

The third rebuild

Eidos is the third time Sei has rebuilt its storage layer, and every rebuild has shipped into a network that was already live. SeiDB replaced the original Cosmos storage stack. The state-store split now on mainnet carved EVM data out into its own database. FlatKV, LittDB, and the off-node archive are the third generation, arriving phase by phase.

Giga’s target is 200,000 transactions per second. Eidos will make sure that Sei's storage smoothly keeps pace.

Disclaimer: The roadmap is subject to change based on development progress, market feedback, and other factors. Actual timelines, figures, and outcomes may vary.

Sources