Sei Network: DeFi-Optimized Cosmos Chain

Purpose-Built for DeFi
Optimizing Sei with ABCI++
Colocating Validators With Better Hardware
The Sei Ecosystem
Sei Token
When Mainnet?

Purpose-Built for DeFi

When building blockchains, we generally try to bucket them into two distinct boxes: general purpose or app chain. General purpose chains for permissionless innovation and app chains for permissioned and specific use cases. But “app chains” are not black and white, rather a spectrum and up to the chain’s discretion. Sei is an upcoming Cosmos chain aiming to be a “DeFi-optimized” layer 1.

What does that mean? It means making fundamental changes (and tradeoffs) to the base layer that will allow DeFi applications to thrive. A built-in order matching engine, sub-second finality, parallelization of orders, single block order execution, and more. All of these customizations are done at the base layer. To be clear, Sei is not a DEX, it is a layer 1 optimized for DeFi. Not a “pure” app chain like THORChain that focuses solely on cross-chain swaps, but one that is built for applications like DEXs, perps, and options to build on top.

To understand why you may want to make these changes at the base layer, we can look to Serum and Solana. Solana is a general purpose layer 1 advertised as putting NASDAQ on-chain, targeting 400ms block times with extremely high throughput. The main thesis of Solana is that order book exchanges will eventually take over AMMs, and the metrics on the chain support it. Serum, an order book application built on top of Solana, is the most used entity and accounts for ~1/3 of Solana program executions. Serum is the “order book layer” on Solana for projects like Mango Markets, Zeta, Atrix, Bonfida, Jupiter, and more to tap into. When people think of Solana, they often think of Serum (although more recently maybe NFTs).

However, there are some drawbacks to this architecture. Most notably, since Solana is a general-purpose chain, Serum (and the apps built on top) are constantly competing for resources with other apps. Activities unrelated to Serum, like gaming and minting NFTs, can drive congestion on the chain and, as we have seen a few times, cause it to halt. Sei “trims the fat” and strips out all the non-DeFi activities from their chain. A rough mental framework is that Sei is if Serum was its own L1; making specific tradeoffs so that the base layer is optimized for DeFi and giving these apps an “unfair advantage” vs. non-DeFi ones.

The main tradeoff here is that Sei will not be as permissionless as Solana, because applications that want to build on top need to be whitelisted by governance. While you lose some of the magic that comes with permissionless innovation, you can create a more optimized environment for your niche. A native order matching engine, price oracle, parallel order execution, and single block order execution are a few of the things Sei has built at the infrastructure level. Sei is an app chain, but don’t be confused; their on-chain order book creates a composable architecture, allowing the CosmWasm apps on Sei to have synchronous composability with each other and share liquidity through the native order matching engine (Sei has mentioned they have >50 teams already interested in building on top). As an IBC-enabled Cosmos chain, there’s async composability for everything else. And on the topic of Solana, there’s a unique Sei ↔︎ Solana angle that we’ll touch on at the end of this report.

Sei achieves some of their optimizations with ABCI++, the upcoming upgrade to Cosmos’ ABCI that allows every step of consensus to be programmable. Sei has been experimenting with ABCI++ for three improvements: optimistic block production, intelligent block propagation, and parallel order execution.

Optimizing Sei With ABCI++

With a focus on order books – block times, finality, and latency are paramount for market makers. MMs need to update their price every block, so shorter block times mean small price updates between blocks, tighter spreads, and less risk MMs need to take on. Anything more than a few hundred milliseconds is impractical (and still probably too high in the long run). A standard Cosmos chain has ~6 second block times which makes order books suboptimal. The beauty of Cosmos, however, is in its customizability, and Sei has been focusing hard on making changes to overload consensus and make it as fast as possible (target ~300-600ms). The three main areas of focus have been:

Optimistic block production
Intelligent block propagation
Parallel order execution

Sei does this by leveraging ABCI++. As a refresher, ABCI is the interface that sits between an application and consensus. Its main role is to execute blocks finalized by consensus. With ABCI, the app only interacted with consensus at decision time and gave it little control over which transactions to pick out of the mempool. ABCI++ adds programmability to every step of consensus, allowing applications to reorder, modify, drop, delay, or add transactions, as well as speed up block times by introducing the ability to optimistically produce blocks.

After the proposed step in consensus, the application is able to start optimistically processing the block in parallel with the pre-vote and pre-commit stages. Sei will then start ‘optimistically’ applying the state changes to a temporary candidate state until accepted by consensus. If not accepted (rare), it’s discarded. There’s a lot of data to process in this step and it can be quite slow. By optimistically processing the state changes, we can speed up block times and reduce latency significantly (~30% for 1s blocks).

In addition to optimistically producing blocks, they are also making improvements to block propagation. In Tendermint, when a block proposer proposes a block they include all transaction details. This is a lot of data! But validators already have access to ~99.9% of these transactions through the gossip process in their local mempool, and thus don’t need to wait to receive these again from the block proposer. Instead of sending all details, the proposer will now just send a hash of every transaction in the block and the validators will be able to quickly reconstruct the block by using the transactions in their own local mempool. Sei calls these two modifications “Twin-Turbo Consensus” and claims ~83% improvement in throughput by implementing them (optimistic block production & intelligent block propagation).

The third modification to the block production process is around order execution. Cosmos chains using ABCI have sequential order procession. In a sequential process, orders are processed one by one regardless of what market they’re in, significantly hindering throughput and exponentially increasing latency as you increase the load. With a parallel process, unique markets that don’t overlap can be processed at the same time. Instead of processing market B’s first order after market A’s, you can process them at the same time. Orders within a specific market still need to be processed sequentially to avoid non-determinism, which happens when two different validators get different results for the same state (e.g. one validator processes user A’s order before user B, but another validator processes user B’s order before A, resulting in conflicting settlement prices for users).

Sei ran some load tests around parallelization (and also colocating validators) to see what kind of improvements they could get in block times, latency, and throughput. Generally, by parallelizing order execution, they were able to see 75-90% reductions in block times vs. sequential and 40-120ms latency for parallel vs. 200-1370ms latency for sequential. Under the scenario of 10,000 orders/block with 20 different contracts (markets), they were able to reduce block times from 1.33s to 0.81s, latency from 371ms to 48ms, and throughput from 7,500 orders/s to 12,200 orders/s. Significant improvements can be seen over all load levels (orders/block), with larger marginal improvements as the load increases.

Besides the three main improvements above, Sei has added other features to the base layer such as:

Native Price Oracle: Oracle built into base layer; validators need to agree on prices when committing to a block. Block won’t be built until validators agree on price. Allows other modules to access reliable price feeds from the on-chain markets.
Single Block Order Execution: Allows an order to be placed and executed in a single block (in Serum it takes multiple blocks).
Order Bundling: Market makers can update prices on multiple markets in one transaction.
Frequent Batch Auctioning: Can aggregate market orders at the end of the block to clear at a single price; with the goal being to try and minimize frontrunning.

Besides the software improvements, Sei has also been testing smaller validator structures and increased hardware requirements. While there are tradeoffs in decentralization, these come with significant performance gains, and again highlight what makes Cosmos unique: customizability.

Colocating Validators With Better Hardware

In the first version of the Sei docs, the recommended specs were similar to a standard Cosmos chain. They’ve since been updated to increase those requirements, and in specific load tests, going even further. Order books can be quite demanding on hardware, and lower spec machines have degraded the overall performance on testnets. While not Solana-level requirements, Sei has made it clear that they want their validators to go above what we see in usual blockchains. They’re also targeting smaller validator sets. While they’ve seen incredible demand with 2,500 validator applications for testnet, they are currently rotating between 250 validators with groups of 50 validating at a time. In addition, they are pushing for colocating validators to reduce latency even further.

Why colocation? With internationally dispersed validators, it takes longer for messages to travel between them and thus higher latency when coming to consensus and producing blocks. In HFT, latency is the name of the game; an order book exchange needs to reduce this as much as possible. Once again, Sei has published the results from some of their tests around colocation. The main takeaways?

Colocation reduces latency by ~46% vs. international dispersion
50 validators is the limit before seeing increased latency by adding more validators

There are obvious tradeoffs here by having all validators in the same geographic region, but the performance gains are hard to dismiss. It is likely that when Sei launches mainnet they will go in this colocated, smaller validator set direction. Quick note: in the chart below, p50/p75/p95 refers to the probability that x% of requests will be faster than a particular value. For example, p50 = the 50th latency percentile, meaning that 50% of requests will be faster than the p50 value for that test. So p95 means 95% of requests will be faster than the p95 value (which is why the p95 number is higher).

Testing is still ongoing for both the software and hardware design, but that hasn’t stopped interested teams from looking at building on Sei. When mainnet goes live, they will have numerous protocols ready to deploy.

The Sei Ecosystem

We touched earlier on how Sei has announced 50+ projects showing interest in building on Sei. While only a few have been announced, there are some notable ones like Vortex, UXD, and Axelar. What’s neat about this is that these three projects all come from different ecosystems.

Vortex: Vortex is the merger of a Cosmos and Terra-based project, Retrograde. Retrograde was aiming to be the “Convex of Terra”, now shifting to becoming a leading perpetuals exchange on Sei. Again, Sei is not a DEX itself and needs projects like Vortex to build on top and utilize Sei’s base layer infrastructure. They’re currently live on testnet and are the main perp protocol announced.
UXD: UXD is a fully collateralized delta-neutral stablecoin from Solana. UXD is minted by users depositing a crypto asset (SOL, BTC, etc.) and then UXD shorting a perp on the other side. UXD will integrate with Vortex to take this short side of the trade (similar to how they use Mango on Solana). Launching on Sei gives UXD access to IBC and the broader Cosmos ecosystem, and the glaring hole in Cosmos DeFi is stablecoins. There’s Kujira’s recently launched stablecoin USK and Agoric’s IST coming soon, but both are CDP-style which can be hard to scale due to capital inefficiency. There’s a large market opportunity for UXD here to expand outside Solana.
Axelar: Axelar is a Cosmos cross-chain messaging protocol, and its main use case is bringing EVM assets to IBC. Osmosis uses Axelar as their canonical bridge/asset issuer for BTC, ETH and USDC, and Sei integrating Axelar’s wrapped assets helps further increase their dominance in the Cosmos ecosystem.

There are a few other protocols listed below like data solutions and synthetics, with more to be announced over the coming weeks. A newly announced project that is quite interesting is Nitro, a Sealevel (Solana’s VM) execution environment, settling on Sei as a Sei L2.

There’s been some confusion around Nitro, as it has been called a “Solana L2”, but the more accurate description is a “Sei L2 running the Solana VM.” This is an optimistic rollup running the general purpose Solana VM Sealevel (same as on Solana) but as a rollup on Sei. Incubated by Sei, the goal is to ease the transition of Solana developers to come over into the Cosmos ecosystem, with future iterations possibly launching as general purpose or app specific rollups on Solana or Ethereum. While Nitro v1 does not settle on Solana and thus does not generate gas fees for SOL, it is a positive development in regards to the SVM taking on greater mindshare from the EVM. The EVM is by far the most popular execution environment today. If you believe that Ethereum’s moat is in the EVM (which many do), then the SVM becoming a standard for rollups is a positive development for Solana. One could argue that Solana’s greatest innovation is in their execution environment. Nitro adds credence to that (and Eclipse, announced shortly after on Celestia).

Being a Sei L2 means Nitro will need to use Sei’s token for data availability and settlement costs. As for a timeline, we’ve seen with the Ethereum rollups how long development has taken, and an added wrinkle here is that the fraud mechanism for a Sealevel rollup will look a bit different (fraud claims?), as there is no global state root to commit to. It’s an interesting idea, but patience will need to be exercised here.

Sei Token

As an L1, the Sei token will be used for staking and gas fees like any other PoS blockchain. But with an aim at low fees, value accrual here is intended to be low (as we see on Solana). The larger expected component to value accrual will be in MEV redistribution. Sei intends to utilize a private off-chain flashbots-style auction where bots can bid for typical MEV transactions like liquidations and arbs. For example, if there is a liquidation with an economic value of ~$100, bots will bid to extract as much of this as possible, and instead of spamming the base layer, will do this off-chain. Bots will compete and bid up for inclusion, and in an efficient market, the winning bid may be ~$99, with $1 to the bot and the remaining $99 distributed to validators and delegators. MEV should trump gas fees by a large margin.

As for airdrops? Sei has been running their incentivized testnet for two months since July and have recently extended for another two, aiming to distribute 1% of supply to participants. Along with the testnet, Sei has hinted at airdrops for the ATOM, LUNA, and SOL communities. There are expected to be more announced in the future.

When Mainnet?

Sei wants to get mainnet out by the end of the year, but is still tinkering with the ABCI++ implementations and validator strategies. Until then, we can keep an eye on the testnet progress and more teased ecosystem announcements. It’s imperative to go to market with a well tested product so momentum doesn’t stall as activity ramps up. They have competition from the now live Injective and dYdX v4 as a pure order book DEX coming soon.

For dYdX, it’s a fundamentally different product and falls more to the right of the app chain spectrum, focusing solely on creating the best trading experience. dYdX achieves efficiency gains by having the orderbook off-chain and stored in validators’ memory; the tradeoff here is that they don’t have a composable on-chain orderbook like Sei and won’t have an ecosystem of apps built around it. Injective is a closer comparison and is already live. Key differences are Injective’s block time of ~2s and that Injective Labs is focused on the app layer in addition to infrastructure, whereas Sei is just focused on the infra level. Competition will be fierce, and to become a major DeFi hub is an ambitious challenge. Will Sei rise to the occasion?