Research

Securing Sei: assessing the relevance of the LtHash collision attack to the Sei blockchain

Sei Labs card reading Sei safe from new lattice hash attack, beside a grid of dials

TL;DR: A new LtHash collision attack is far cheaper than the hash was designed to allow, but it only works on states trillions of times larger than Sei's. The attack needs at least 550^8 (about 8.4 sextillion) distinct entries across two colliding states. The Sei blockchain holds about 700 million keys in FlatKV today, so Sei Labs finds the attack practically infeasible against Sei.

Why a new attack on LtHash matters to Sei

Cryptographic attacks keep getting better, and as AI advances, new ones are likely to arrive faster. Sei Labs proactively monitors these breakthroughs and the state of the chain so that Sei's users stay protected. In September 2026, researchers at the Chinese Academy of Sciences published a collision attack on LtHash, the lattice hash Sei uses to fingerprint its state. The paper lists Sei among the blockchains that use the LtHash16 parameters it targets. Sei Labs' analysis finds the attack practically infeasible against Sei, because it needs far more state than Sei, or any other blockchain, holds.

What the new LtHash collision attack requires

LtHash is an incremental, homomorphic hash function designed to efficiently maintain a commitment to a set of elements. Rather than recomputing the hash of the entire set whenever an element is added or removed, LtHash allows the commitment to be updated through modular addition and subtraction.

A collision occurs when two distinct sets produce the same LtHash value. After cancelling any elements common to both sets, this is equivalent to finding a nonzero vector z with entries in {-1,0,1} such that Az=0 mod 2^d. This is an instance of the ternary Short Integer Solution (SIS) problem, which underlies the collision resistance of LtHash.

A recent paper introduces a more efficient method for solving this problem by progressively constructing a ternary solution modulo higher powers of two. The resulting attack has an expected oracle-query complexity of approximately 2^81.07, below the intended 128-bit collision-security level.

However, the construction has an important limitation: the specific LtHash16 construction analyzed in the paper requires at least 550^8 (approximately 2^72.83) distinct elements across the two colliding sets.

This exceptionally large support requirement is central to assessing the attack's practical relevance to Sei, where the elements contributing to LtHash correspond to logically present key-value pairs in the blockchain state.

How Sei's state feeds LtHash

In Sei, the state committed by LtHash is stored as key-value pairs across four FlatKV databases: accountDB, storageDB, codeDB, and miscDB. Each logically present key-value pair contributes an element to the LtHash state commitment, while deleted or absent entries are excluded. Consequently, the number of LtHash-contributing elements is bounded by the total number of logically present key-value pairs across these databases.

How Sei's state size compares with what the attack needs

Sei currently has 700 million keys migrated to FlatKV across its four databases, with another 300 million keys planned for migration in a later phase. Thus, each state contains at most 1 billion (approximately 2^29.90) entries. For two states, the combined number of contributing elements is at most 2(2^29.90)<2^31<2^72.83. Therefore, the states at this scale cannot accommodate the collision sets required by this particular attack.

Importantly, 1 billion keys is not a protocol-enforced upper bound. Sei's state can continue growing as new keys are created. Nevertheless, for this attack to apply to two valid states, their combined number of contributing elements must reach at least 550^8. Assuming approximately equal-sized states, each would need around 2^71.83 entries, which is far beyond the scale of existing blockchain systems.

For perspective, Ethereum, one of the largest smart-contract blockchains, has approximately 2.1 billion occupied state entries, including accounts, contract-storage slots and unique contract bytecodes. This is still roughly 2 trillion times smaller than the number required per state by the attack.

The minimum collision support also implies substantial storage requirements. Even assuming a conservative minimum of just 9 bytes per key-value entry, a state containing 2^71.83 entries would require approximately 37.7 ZB of storage, excluding database overhead. At that scale, the challenge of storing and maintaining the blockchain state would itself be an overwhelming practical obstacle, long before this collision attack would become relevant. Thus, while Sei does not currently impose a hard upper bound on the number of state entries, the enormous gap between realistic state sizes and the minimum collision support required by the attack makes this particular attack practically infeasible.

Sources