How this works

Sei keeps its state in memIAVL: an IAVL tree laid out flat on disk as kvs (keys and values), nodes (branches) and leaves. Every branch and leaf record is 48 bytes, and 32 of them are a SHA-256 hash — random bytes no compressor touches, a third of the state, and a pure function of the rest.

So the hashes are cut out (48 → 16 bytes per record) and your machine computes them again. Records are stored in post-order: children always come before their parent, so the hashes are rebuilt in one pass — leaves in parallel, branches by independent subtrees.

The historical state store is not shipped at all: a node does not need it to follow the chain. What remains is compressed with zstd and split into parts.

1. Before publishing, the app_hash of the published height is taken from the header of the next block and must agree across independent public RPCs.
2. The Tendermint state is written by a light-client bootstrap: headers verified by signatures, cross-checked against a second RPC, the block itself checked against the verified header and its results against LastResultsHash.
3. On your machine every part is checked by sha256 while it downloads.
4. The stripped hashes are recomputed on your machine, not copied from ours, and every tree root must equal the store hash in the snapshot's own __metadata.
5. On start the node itself compares the memIAVL app_hash with the verified Tendermint state and refuses to run on a mismatch.

Our node is never stopped. The memIAVL snapshot directory is immutable once written, so it is hard-linked — no bytes copied. From the changelog only closed segments are taken; the height of the copy is the last block in them. The Tendermint state for exactly that height comes from the light-client bootstrap above, a few kilobytes instead of a copy of the node's databases.

Then the parts are built while the node runs on: large files are cut into byte ranges and their hashes stripped on the fly, small files go into tar parts, everything is compressed with zstd. Parts are named by their sha256, so a part that did not change is never stored twice. The manifest is swapped only after every part is in place.

Earlier versions stopped the node for each copy. Sei takes 9–12 minutes to stop, and every stop also killed the memIAVL snapshot it was writing (3–5 hours on our disk), so the changelog grew without end. The light-client bootstrap removed the stop.

The snapshot is as old as the last capture plus its build: up to about an hour and a half. The changelog in it grows until the node finishes its next memIAVL snapshot, and with it the replay time on your first start. Network upgrades need the matching seid; the manifest always names the version the data was written with. Latencies on the Endpoints page are from our server, not from yours.