Sei, General Purpose L1 for Trading

Key Takeaways

• Sei aims to combine the benefits of both a general-purpose chain and app chains, positioning itself as a trading-optimized general-purpose chain.

• Sei offers a fast and convenient trading environment through its twin-turbo consensus, parallel transaction processing, and its own order matching engine.

• From a user experience perspective, transaction finality is one of the most crucial metrics, and Sei is the L1 network that has achieved the fastest finality.

1. General Purpose Chain vs. App-Chain

1.1 General Purpose Chain

The blockchain industry has experienced rapid growth since the DeFi Summer, and according to DefiLlama, there are currently 182 mainnets. The proliferation of blockchains can be attributed to their limited scalability. Due to the inherent constraints of distributed server-maintained blockchain networks, they are inevitably less scalable than centralized systems. A prime example is the DeFi Summer on the Ethereum network in 2020.

At that time, the majority of the total value locked (TVL) was concentrated on the Ethereum network, despite the existence of numerous blockchain networks. With several DeFi protocols already in existence, including Uniswap, Synthetix, bZx, and Compound, the launch of Compound’s COMP token on June 16, 2020, marked the beginning of DeFi Summer. Users could earn COMP tokens as rewards for using Compound, which attracted even more users due to the incentives provided.

Compound was quickly followed by Aave, Yearn Finance, and Curve, and the Ethereum network was increasingly crowded with DeFi users, including Sushi Swap’s vampire attack and Uniswap’s token launch. Transaction fees on the Ethereum network are determined by gas fees, which increase as the network becomes more congested, causing the network’s gas fees to skyrocket at this time. Later, in early 2021, as the crypto market bull run began, the high gas fees on the Ethereum network became a persistent problem, causing users to leave Ethereum for other faster and cheaper networks (e.g. BNB, Polygon).

BNB and Polygon forked Ethereum’s client and edit block times and sizes, Solana introduced a new consensus algorithm and parallelization of transactions to improve scalability, and various blockchains used their own methods to achieve high scalability. But even these were not the ultimate solution, as they are still ‘general-purpose chains’.

The term “general-purpose chain” is used to describe a blockchain network that has a broad range of potential applications and uses, which is equipped with a virtual machine such as EVM or SVM. Most of the blockchain networks we know (Ex. Ethereum, Solana, BNB, Polygon, Arbitrum, etc…) belong to the general-purpose chain category.

General-purpose blockchains offer the benefits of simple ecosystem creation and network effects, as they can host a multitude of applications. However, they also come with several drawbacks. First, scalability can be an issue, as all transaction types within the network compete for the same resources, such as computation and storage. Second, dependency is a concern since apps operating on these chains rely on the network’s consensus algorithm and must adhere to network-level upgrades as they occur. Lastly, customization is limited, as decentralized applications (DeFi, gaming, or social media) are constrained by the Ethereum Virtual Machine (EVM) environment, making it nearly impossible to tailor network elements for optimizing specific features.

1.2 App-chain

One blockchain that emerged as a solution to a particular problem is the concept of app-chain(Application Specific Chain). An app-chain is a network where all components of the blockchain can be tailored to a specific application, which was first pioneered by Cosmos. Cosmos provides a tool called the Cosmos SDK, which simplifies the creation of an app-chain. A blockchain is made up of three main functions: network communication between nodes, consensus on block creation, and applications. The Cosmos SDK includes the Tendermint core by default, which handles communication and consensus, allowing developers to concentrate on the application, creating an app-chain customized for a specific purpose.

(TVL ranking as of Apr 7, 2023 | Source: DefiLlama)

While app-chains have some compelling advantages over general-purpose chains, the reality is that there are no app-chains in the top 15 by TVL. Of course, Cronos and Kava are blockchains built with the Cosmos SDK. However, since Cronos and Kava introduce EVM and a lot of dApps are deployed, it would be more appropriate to classify them as general-purpose chains. Moving down the TVL rankings, the first app-chain to appear is Osmosis at #17.

Does this mean that general-purpose chains are superior to app-chain? Not really, because app-chain solves many of the drawbacks of general-purpose chains, such as scalability, dependencies, and lack of customization. Nevertheless, there are several reasons why app-chain has a lower TVL than general-purpose chains.

Since app-chains are optimized only for specific applications, they cannot establish a diverse ecosystem and cannot attract many users. Additionally, even with a bridge protocol like IBC, an app-chain is essentially a separate blockchain, making it inconvenient for users to use the service. Similarly, due to the disadvantage of having to use a bridge, app-chain applications are less composable with various DApps outside the network.

In this context, composability refers to the degree of interaction between dApps, specifically the ability of one smart contract to read or write to another. For instance, Arrakis Finance automates liquidity supply positions on Uniswap V3 by reading data from Uniswap V3 and adjusting liquidity supply. Thus, they are composable.

In particular, when smart contracts can interact with each other within a block of time, this is called synchronous composability. For example, arbitrage trading with flash-loan is a good example of synchronous composability because it allows you to borrow a large amount of funds, swap them, and pay them back within a single transaction. dApps that share a specific blockchain, such as DeFi protocols on top of Ethereum, are usually synchronously composable with each other.

In contrast, asynchronous composability is when the interaction between smart contracts occurs within an unspecified time range. A typical example is when dApps on different blockchains interact with each other. Let’s say you want to buy Y tokens on chain B with X tokens held on chain A. The user first sends the X tokens to a specific smart contract on the A chain, and the smart contract on the B chain will verify it and send the Y tokens to the user. In a scenario where multiple blockchains interact, determining the time required to complete the transaction on the destination chain is challenging and protracted. This is because the process necessitates verification of the other chain’s activity, significantly diminishing the user experience.

1.3 Sei, General Purpose L1 for Trading

To summarize, general-purpose chains and app-chains have a trade-off relationship. The advantages of general-purpose chains (e.g., ecosystem building, composability) become the disadvantages of app chains, and the advantages of app-chains (e.g., scalability, optimization) become the disadvantages of general-purpose chains. However, there is a project that tries to take the best of both worlds, and that is Sei.

Sei is a general-purpose chain focused on trading, not an app chain specialized for specific applications. In other words, Sei is a trading-optimized blockchain with various features such as Twin-Turbo Consensus, transaction parallelism, and its own native order matching engine, which we will discuss below, and the various DeFi protocols listed above can benefit from this optimized environment. It’s basically a general-purpose chain that actively leverages the benefits of app-chains.

Why was Sei developed as a Layer 1? The team at Sei Labs initially considered creating Sei as a Layer 2 solution on Ethereum. However, they identified several drawbacks associated with Layer 2 rollups. First, decentralization is an issue as all Layer 2 solutions rely on a centralized sequencer, which is a single entity in charge of executing user transactions. This raises serious concerns regarding resistance to censorship and the guarantee of continuous operation. Second, throughput is a limitation, as the maximum throughput of Layer 2 is restricted by the block space of the underlying Layer 1 to which it connects, resulting in substantial challenges when it comes to scaling.

Thanks to this new concept, Sei was able to raise $5M in August 2022 from leading VCs including Multicoin Capital, Coinbase Ventures, GSR, and Delphi Digital, and $30M in April 2023 from Jump Crypto, Distributed Global, Multicoin Capital, and Hypersphere Ventures. What features has Sei added that make it the best blockchain for trading?

2. Order Matching Systems

The Sei modifies Tendermint core to optimize it for trading in a number of ways, but one of the most notable differences is its own native order matching engine. (Sei doesn’t manage order book, but it just offers an order-matching framework.) The various DeFi protocols on top of the Sei can utilize this order matching engine. One of the big problems with the existing DeFi ecosystem is that liquidity is fragmented for each DeFi protocol, but with the Sei, all DeFi protocols share a single order matching engine that can provide deep liquidity.

This design of the Sei solves the so-called “Exchange Trilemma”. The Exchange Trilemma is the difficulty of a decentralized trading system to satisfy at least two of the following: scalability, decentralization, and capital efficiency. Scalability refers to how large and frequent transactions an exchange can handle, and it applies not only to trading by users but also to the liquidity provisioning behavior of liquidity providers. Decentralization is about whether there is a single point of failure. Capital efficiency is how well the liquidity provided is utilized for trading.

The first product that satisfies both decentralization and scalability is an AMM DEX such as Uniswap V2. It is decentralized because it runs on the blockchain, and it solves the scalability problem by simplifying the trading process through AMM, but in terms of capital efficiency, it is very inefficient because liquidity is supplied across the entire price range. The second product that satisfies both scalability and capital efficiency is centralized exchange (CEX). CEXs are highly capital efficient and scalable because they utilize an order book on a centralized server, but they are less decentralized. Finally, there is an on-chain order book that combines both capital efficiency and decentralization. Since the order book runs on the blockchain, it is highly decentralized and capital efficient, but it has the disadvantage that it is not scalable and often crashes, such as Serum, causing problems with liveness. Sei basically utilizes an order matching engine and tries to solve the exchange trilemma by introducing features such as Twin-Turbo Consensus and transaction parallelism to improve scalability.

3. Key Features of Sei

Let’s take a look at how Sei was able to solve the exchange trilemma by improving scalability.

3.1 Twin-Turbo Consensus

Twin-Turbo Consensus includes two features: 1) Intelligent Block Propagation for efficient block propagation and 2) Optimistic Block Processing for increased scalability by reducing block times.

3.1.1 Intelligent Block Propagation

In blockchain, full nodes play a very important role in the security of the network. When a full node receives a transaction from the network, it downloads it, checks the validity, adds it to its local mempool if it is valid, and propagates the transaction to other random full nodes (the gossip process). Not all full nodes create blocks, but all block proposers are full nodes.

In a typical blockchain network, a block proposer gathers the transactions in its local mempool, forms them into a block, and propagates it to the network. In this process, a single block containing all transaction data is propagated to the network, and nodes use a lot of bandwidth for this process. This is where Sei’s Intelligent Block Propagation comes in.

According to Jay, a co-founder of Sei, full nodes already have most (99.99%) of the transactions in their local mempools through the gossip process. This means that even though full nodes already have almost all of the transactions, regular blockchain networks are still propagating blocks with the same transaction data. This is a kind of a waste of bandwidth.

In the Sei, a block proposer does not include transaction data in a block proposal, but rather 1) a hash value of the transactions, and 2) a Block ID, which is a reference to the block. The hash value of a transaction is a hash function summarizing the existing transaction data, so it has the advantage of being small in size. The block proposer first propagates the block proposal to the network as shown in the figure below, and then propagates the complete block in small pieces.

If a validator receiving a block proposal from a block proposer already has all the transactions corresponding to the hash value in their local mempool, they will reconstruct the block from their local mempool, rather than waiting for the complete block to reach them. If, in a very small probability, a particular validator is missing a transaction in its local mempool, it can wait until the complete block reaches it.

The benefit of this intelligent block propagation process is that it dramatically reduces the time it takes for validators to receive blocks. According to the co-founder, this process has been shown to increase the overall scalability of the Sei by 40%.

3.1.2 Optimistic Block Processing

The Sei uses Tendermint core, but with a few modifications to dramatically reduce block times and increase scalability. Tendermint core is a consensus engine that uses a combination of Delegated Proof of Stake (DPoS) and PBFT consensus algorithms. The process of Tendermint BFT consensus looks like:

1. Propose: The validator in line to produce the block (the leader) proposes the block to the other validators.

2. Prevote: The remaining validators validate the block received from the leader and vote on it. If there is more than a 2/3 consensus, the block moves to the Precommit phase.

3. Precommit: Validators once again reach a consensus of 2/3 or more for the blocks they received.

4. Commit: Finally, the validators return the same agreed-upon block to the client.

Tendermint BFT, or PBFT, is characterized by two 2/3+ consensus processes. The reason for the two seemingly identical consensus processes is that blockchains are asynchronous networks. An asynchronous network is an environment where the interaction of messages can be delayed indefinitely during the communication process. In a synchronous network, a single 2/3+ consensus process is fine, but in an asynchronous network, there is no way to determine whether a disconnected validator is a Byzantine (malicious) node or a node that is offline, and a single consensus process would risk network collapse, so two consensus processes are a safe bet.

So, how does Sei’s Optimistic Block Processing modify the Tendermint BFT process? First of all, the figure below is a diagram of the general Tendermint BFT process. As you can see, it goes through the process of Propose — Prevote — Precommit — Commit, and there is a block processing process between Precommit and Commit.

However, assuming that there are very few malicious nodes, the validators have already received the data they need to compute in the Propose phase from the Prevote phase. Therefore, in order to further reduce the block time, the Sei starts to process the computation in parallel with Prevote. Reducing block time through Optimistic Block Processing shouldn’t be a problem because most of the time there is no question about the validity of a block, but if a block is rejected by the network during the Prevote and Precommit process while performing a computation, it can simply be discarded.

The block time saved by Optimistic Block Processing is determined by the minimum of 1) the time it takes to Prevote and Precommit and 2) (number of transactions * time to compute a single transaction). Here’s an example. In the figure above, if we follow the normal Tendermint BFT method, the total block time is 200+150+150+400+100, which is 1000ms. Here, we can see that Optimistic Block Processing saves 300ms, the time it takes to Prevote and Precommit, reducing the block time to 700ms. If the block size is constant, the reduction in block time from 1000ms to 700ms means that there are 1000/700, or about 1.43 times more blocks in the same amount of time, which is a 43% increase in scalability.

3.2 Transaction Parallelization

An additional approach employed by the Sei to enhance scalability is the parallelization of transactions. The Ethereum Virtual Machine (EVM), the blockchain industry’s most prevalent virtual machine, processes transactions sequentially, which inherently restricts scalability. By default, the Cosmos SDK, upon which the Sei is built, also processes transactions in a serial fashion.

In Cosmos app-chain, when a block is received, validators execute the BeginBlock logic, DeliverTx, and EndBlock logic in this order, while the Sei modifies DeliverTx and EndBlock to process transactions in parallel.

First of all, the DeliverTx process handles transactions such as token transfers, governance proposals, and smart contract calls, and it is important to ensure that none of the transactions being processed in parallel refer to the same key. For example, the two transactions of A sending X tokens to B and C sending Y tokens to D can be processed in parallel, but the two transactions of A sending X tokens to B and B sending X tokens to C cannot be processed in parallel, so they will be processed in series.

In order to parallelize multiple transactions, we need to make sure that they do not refer to the same key, and to do this, Sei construct a DAG (Directed Acyclic Graph) to check the dependencies between transactions before executing them. In the image above, let’s assume that the DAG shows that R3 in the middle is dependent on R2 in the first column, and R3 in the third column is dependent on W1 in the middle. In result, transactions will be processed as shown on the right.

In the last part of the block, EndBlock, transactions related to the matching engine are executed by the native order matching engine. Again, transactions related to the matching engine are not processed in serial order, but in parallel once it is confirmed that they are not related to each other.

By default, the network is designed to assume that all transactions are unrelated and process them all at once, and if there are related transactions, only those transactions will fail. Therefore, developers of apps on top of Sei’s order matching engine must first filter out which transactions are related and which are not.

The table above shows the results of experimenting with parallelization on the Sei, which shows a 60–90% performance improvement in block time, TPS, etc. compared to one without parallelization.

3.3 Native Price Oracles

The Sei has its own oracle module that gets the prices of tokens traded on the network. To do this, validators agree on the prices of the tokens listed on the network every block, and every block (less than a second) the token prices are updated with the new prices.

The consensus process for deciding the price works as follows: during the voting period, each validator submits the exchange rate they believe the token should be, and the weighted average of the collected values is selected as the oracle price for the Sei. Validators who do not participate in setting the token price, or who provide malicious prices that deviate too far from the median, will accumulate a number called ‘miss count’, and if the miss count becomes too high, their staked tokens will be slashed as a penalty.

3.4 Native Order Matching Engine

Sei has its own order matching engine. Therefore, various DeFi applications on top of Sei can utilize it to build order book protocols. For a simple example, let’s say that there are ‘Potato Dex’ and ‘Sweet Potato Dex’ on the SEI. If user A submits an order to sell 1 ETH on the Potato Dex for $2,000, and user B submits an order to buy 1 ETH on the Sweet Potato Dex at the market price, the Sei’s order matching engine will match the two orders. In general, DeFi networks suffer from liquidity fragmentation as each DeFi often maintains its own liquidity, but Sei provides a very deep liquidity pool where all liquidity related to the matching engine is brought together, minimizing users’ financial losses due to collateral effects such as slippage.

Sei supports the following ordering methods

• Limit orders: An order to buy or sell an asset at a specific price. When a limit order transaction comes in from a user, it is added to the order book and is later filled by a market order.

• Market orders: These are orders to buy or sell an asset at a price that is currently available for immediate execution. If there is enough liquidity in the order book, the trade will be executed immediately, and you can set a maximum slippage to prevent the order from being filled at a price that is farther out than you thought.

• FOK order (Fill-or-kill order): A form of market order where the trade is executed if there is sufficient liquidity, and not executed at all if there is not. FOK orders are never partially filled.

• Stop-loss order: An order to buy or sell at the market price if the price of an asset you own reaches a pre-set price. This is an automated trade order feature that limits your investment losses.

• Cancel order: An order that cancels an order that the user has already submitted.

There are no transaction fees collected by the order matching engine. In the future, the governance of the Sei may allow users to charge transaction fees, and various DeFi applications on top of the order matching engine may set their own transaction fees at the service level. Since there are basically no transaction fees charged at the network level, it is unlikely that developers will have to set very high transaction fees to compete on top of this.

3.5 Frequent Batch Auctioning

If the transactions related to matching engine are processed in order, a validator can preview the transactions in the mempool and maliciously extract MEV to harm the user. For example, if a user places a market order to buy a large amount of ETH, a validator can preview this and buy a large amount of ETH before the user, forcing the user to buy a large amount of ETH at a higher price. To prevent such malicious MEVs, the Sei aggregates all market orders and processes them at once at the same price.

For example, if the ETH/USDC order book market has sell orders of 1 ETH at $1,900 and $2,000, and two market orders to buy 1 ETH come in, this is not the case that the first market order will be filled at $1,900 and the second at $2,000, but both market orders will be filled at $1,950, the average of $1,900 and $2,000. In this case, even if the validator were to preview your market order and front-run it to try to extract a malicious MEV, it would be pointless because it would be executed at the same price as everyone else.

3.6 Transaction Order Bundling

With the ability to bundle transactions related to matching engine and process them all at once, the Sei can reduce the amount of gas consumed by the network or lower the latency of transactions. There are two ways to bundle orders, as follows

• Client Order Bundling: On the Sei, you can place orders in multiple markets simultaneously in a single transaction. For example, you can place multiple orders to buy BTC/USDC spot, sell BTC/USDC futures, and sell ETH/USDC spot within a single transaction. This feature allows market makers to efficiently provide liquidity on the Sei’s order matching engine.

• Chain Level Order Bundling: Transactions related to matching engine require the creation of a virtual machine instance, but in Sei, the transactions of each market are aggregated together to create a single virtual machine instance. For example, if there are 10 transactions in the BTC/USDC market, they are bundled together and processed as one. Thanks to this operation, Sei is able to reduce the latency of trade orders to around 1 ms, which results in an increase in TPS.

4. Compare with other L1s (Sui, Aptos, Solana, Upcoming L1s)

The aforementioned technical distinctions set the Sei apart from other app-chains within the Cosmos ecosystem, while also allowing it to benefit from the Cosmos ecosystem’s technical capabilities. Moreover, although Sei developers have primarily focused on financial transactions when designing the infrastructure, they aspire to evolve into a general-purpose blockchain that extends beyond the financial sector. As a result, the Sei’s comparison will not be with other app-chains or sector-specific chains in the Cosmos ecosystem, but rather with Aptos, Sui, and Solana — emerging general-purpose layer 1 chains in the market. So, how does Sei measure up against them?

4.1 Sei vs. AptoSui: Rust vs. Move

First, let’s compare Sei to Aptos and Sui, which are the most prominent layer-1 blockchains in the market today and represent the next generation of general-purpose blockchains. When comparing Sei to Aptos and Sui, our main focus is on the size of the developer community. At the end of the day, all of them are aiming to become successful decentralized platforms by providing an environment where various applications can be built on top of the blockchain database. And the developer community is just as important as scalability to ensure that these applications are built and actually implemented. No matter how fast and efficient the infrastructure is, if there are no builders creating products on the platform, what does scalability mean? For starters, Sei has access to a much larger developer community than Aptos and Sui. Aptos and Sui use their own programming language, Move (and even Aptos’ Move and Sui’s Move are slightly different), so developers have to learn a new language, Move, to build on top of Aptos and Sui. In some ways, Move has the advantage of being the most specialized language for blockchain, but the language’s usability is limited to certain sectors, making it difficult for developers to participate in the Aptos and Sui ecosystems.

In the case of Sei, on the other hand, they choose Rust as their programming language because it’s more general-purpose than just blockchain. According to data published by SlashData, Rust is not only used for blockchain but is actually used more for AR/VR (Augmented Reality/Virtual Reality) than blockchain. Not only that, the Rust developer community has seen explosive growth, nearly tripling in 24 months as of Q1 2022 (from around 600,000 developers in 2020 to over 2.2 million in 2022). It’s not just the blockchain that’s driving the growth, but the language itself, which is very popular among developers, making it a more stable choice for developers. Sei also has a comparative advantage when it comes to building a community of builders, as it has a larger developer community than Aptos and Sui (developers in the Cosmos ecosystem also use Rust for deploying smart contract on top on Cosmwasm, and Solana developers use Rust, so they have an advantage over Aptos and Sui when it comes to onboarding developers). The developer experience is just as important as the UI/UX to build a popular blockchain, and Sei seems to have taken care of that, at least in terms of using an existing(and popular) language.

4.2 Time To Finality Actually Matters

Many people focus on TPS (transactions per second) when calculating the performance and scalability of a blockchain, but it’s actually a very ambiguous metric. Let me explain why with an example. If blockchain A can hold a total of 600,000 transactions in a block, and the time it takes to create a block is 1 minute, its TPS (=number of tx in a block / block time in seconds) will be 10,000, but in reality, it takes 1 minute for 600,000 transactions to be confirmed on the network, so it can’t be said that it processes 10,000 transactions per second in real time. Since TPS is just the throughput of the blockchain divided by the number of seconds, the apparent TPS can actually feel different to users. If the example is not extreme enough, you could dramatically increase the number of transactions per block and increase the block time to one hour and still get a very high TPS (but users would have to wait an hour for their transactions to be confirmed on the network). For this reason, when discussing the scalability of blockchains these days, it seems to be more common to use TTF (Time to Finality), a metric that shows how long it takes for a transaction to be confirmed, rather than TPS. Especially for a layer 1 chain focused on financial transactions like the Sei, it’s very important that transactions are processed and confirmed on the network immediately, so it’s important to make TTF as fast as possible.

The graph above shows the TTF of other layer 1 blockchains that are currently being compared to the Sei. Currently, according to the Sei team, Sei has achieved a TTF of 450ms (0.45 seconds) in a public testnet environment. If it achieves a TTF of 300ms in the mainnet environment, it will be the shortest TTF blockchain in existence. If Sei aims to provide the user experience of a centralized exchange on a decentralized exchange, reducing TTF is a very smart move.

5. Ecosystem

5.1 Infrastructure

• Andromeda — Andromeda provides the andromeda Operating System, also known as aOS, to help developers easily build Web3 apps.

• Paddle — Paddle is a layer 2 network based on the Cosmos ecosystem and is characterized by its support for MoveVM.

• Mintscan — Mintscan is the leading multi-chain explorer of the Cosmos ecosystem, developed by Cosmostation.

• Skip Protocol — Skip Protocol provides a solution to minimize and decentralize the negative impact of MEVs in the Cosmos ecosystem, similar to Ethereum’s Flashbot team.

• Babylon Chain — Babylon Chain is an app-chain in the Cosmos ecosystem that allows other app-chains to commit their state root on the Bitcoin network through Babylon Chain, allowing them to leverage some of the security of the Bitcoin network.

• Nitro SVM — Nitro SVM is a rollup network based on the Sei bringing SVM, the virtual machine used by Solana, to the Cosmos ecosystem.

• ConvergenceRFQ — Convergence RFQ is an on-chain RFQ solution optimized for liquidity providers, protocols, and market makers, enabling fast and secure trading of on-chain derivatives.

• KYVE — The KYVE Network is a data layer solution for the Cosmos ecosystem utilizing Arweave, storing massive amounts of data from various blockchains on Arweave and making them more accessible.

• Elixir — Elixir is a market-making protocol that various exchanges can easily adopt, decentralizing the highly permissioned world of market-making and allowing anyone to participate.

• Hana — Hana network is a network that utilizes ZK technology and the UTXO model to grant privacy attributes to assets on various networks.

• Strobe — Strobe provides a module that enables the execution of smart contracts written in the Move language on the Cosmos appchain, and will enable the Move language to be utilized on the Sei.

• Magpy — Magpy is a protocol that allows you to create trading bots on various DeFi protocols across multiple chains without coding. This allows you to automate a variety of trades, including DCA and hedging.

5.2 DEX

• SushiSwap — SushiSwap is the most prominent DEX protocol alongside Ethereum’s Uniswap. Sushi Swap acquired Vortex Protocol, a futures dex that previously existed on the Sei, and will launch a protocol utilizing Sei’s own order order matching engine.

• White Whale — White Whale is a protocol designed to solve the problem of fragmented liquidity by acting as a liquidity hub.

• Cypher — Cypher is an order book trading protocol that utilizes an open book (a community fork of Serum), and it is expected to launch the protocol utilizing Sei’s order matching engine.

• Kryptonite — Kryptonite is an AMM and staking protocol that allows users to deposit stablecoins or lend stablecoins using bAssets, a liquid staking token. SEI, the token of Sei, will be the first bAssets to be adopted.

• Crescent — Crescent is a DeFi-specific app-chain in the Cosmos ecosystem that offers swaps, LP supply, liquid staking, and more.

• Blink — Blink Finance is a multi-chain leverage trading protocol that offers institutional-specific features. It offers something called the Blink Margin Engine, which allows traders to leverage trade on multichain with undercollateralized loans.

• LFW — Linked Finance World is introducing a bridge aggregator as a cross-chain swap solution, making it easy to swap assets from one chain for other assets from another chain. In the future, LFW will introduce various features such as launchpad, staking, and order book.

• UNO — UNO is a DeFi platform powered by Polygon, BSC, Aurora, Avalanche, and others that introduces a LP pool with high APR for each network, making it easy to yield farm within one platform.

• Sola-X — Sola-X is a DeFi protocol with an optimized UX, where user-supplied liquidity is algorithmically rebalanced into various liquidity pools, JIT(Just-in-time) liquidity is supplied to minimize slippage, and arbitrage trades can be made on their own to generate interest.

• MC2 Fi — MC2 Fi is a protocol that utilizes the transparency of on-chain data on the blockchain to allow users to trade by emulating other successful traders.

• Sparrow Swap — Sparrow Swap is a native DEX protocol on the Sei that allows for swaps, liquidity provision, and other activities.

• Fuzio — Fuzio is a protocol that offers a variety of decentralized finance services, including a DEX, options, launchpad, liquid staking, and more.

• Sea Swap — Sea Swap is a native protocol to the Sei that provides a variety of features including OTC swaps, bonding curve launchpad, DEX, token generator, and more.

• Simba Exchange — Simba is a protocol native to the Sei that utilizes Sei’s own order matching engine to provide order book DEX.

5.3 Stablecoin / Staking

• UXD — UXD is an over-collateralized decentralized stablecoin protocol built on Solana. It employs a novel approach to collateralizing a stablecoin by maintaining a delta-neutral position, achieved through purchasing 50% spot and shorting 50% futures. Depending on the market conditions, the funding fee will be distributed to UXD token holders.

• Stride — Stride is a liquid staking protocol in the Cosmos ecosystem that allows users to stake ATOM and receive interest and stATOM, a liquid staking token. Stride will also support liquid staking of SEI, the token of the Sei, in the future.

• Inter Protocol — Inter protocol is a stablecoin protocol based on the Agoric app-chain that allows smart contract development in JavaScript. Users can deposit USDT or USDC and issue IST with overcollateralization. Inter protocol will support their stablecoin, IST, on the Sei.

5.4 Synthetic Asset

• DeFund — DeFund is a protocol that makes it easy for anyone to create ETF tokens. The advantage is that it connects to many protocols via IBC and bridges, allowing you to create ETFs with a variety of assets, including tokens, RWAs, options, gold, and more.

• SYNTHR — Synthr is a protocol for trading synthetic assets with minimal slippage across various networks (Ethereum, BNB, Polygon, Sei, Sui, Aptos, etc.).

5.5 Bridge

• Multichain — Multichain, formerly known as Anyswap, is one of the oldest and most popular bridge protocols. It supports over 90 blockchains.

• Axelar Network — Axelar Network is one of the leading bridge app-chains between the Cosmos ecosystem and other ecosystems, where nodes participate in bridge validation.

• Celer Network — Celer Network primarily supports bridges between EVM networks, but has recently added support for non-EVM networks.

• Gravity Bridge — Gravity Bridge is also one of the leading bridge app-chains alongside the Cosmos ecosystem, with the main goal of connecting Ethereum and Cosmos.

• Router Protocol — Like Axelar and Gravity, Router Protocol is also an app-chain specialized for bridge, but with cross-chain trading capabilities.

• Swing — Swing is a cross-chain asset management protocol in the form of an aggregator that supports various bridges.

5.6 Wallet

• Fin Wallet — Unlike other wallets that are used in various ecosystems, Fin Wallet is the first Sei-native wallet created exclusively for Sei Ecosystem.

• Keplr — The Keplr wallet is the most prominent multi-chain wallet in the Cosmos ecosystem.

• Frontier — The Frontier wallet is a wallet that supports a wide variety of networks including Ethereum, BNB, Polygon, Aptos, as well as Cosmos app-chains.

• Coin98 — Coin98 Super App is a super app that offers a wide range of features, including a multi-chain wallet, trading, DeFi, and more.

• Apollo — Apollo will support a multi-sig wallet called Apollo Safe on the Sei.

• Leap — Leap is a wallet specialized for the Cosmos ecosystem, aimed at mobile super apps.

5.7 Oracle

• Band Protocol — Band Protocol is the leading decentralized oracle app-chain in the Cosmos ecosystem.

• Pyth Network — Pyth Network is an oracle that fetches market data from more than 80 first-party sources, starting with Solana and extending its support to various networks.

5.8 Gaming / Social / NFTs

• Truts — Truts is a Web3 social platform that makes it easy for anyone to create a variety of communities where people can gather and interact.

• Gelotto — Gelotto is a luck-based mini-game platform built on the Juno network and the IBC ecosystem.

• Entice — Entice is a P2E platform based on very simple mobile games.

• Fable — Fable League is an on-chain esports league and minigame publisher that aims to become a gaming platform for other NFT projects to compete against each other.

• Space ID — Space ID is a platform for registering and trading web3 domains, and in addition to the .bnb, .arb, and .eth it currently supports, it will also support .sei addresses, which are domains on the Sei.

• Seer — Seer is an all-in-one social media platform that allows you to create groups and connect with different people online, as well as offer ads, chatGPT, and many other features.

• Mizu Market — Mizu is the first native NFT marketplace on the Sei.

• SenSei Fi — SenSei Fi applies a bit of game theory to DeFi, allowing users to manage their accounts and earn a steady rate with low risk.

• Dagora — Dagora is a core NFT marketplace within the Coin98 ecosystem, initially supporting BNB and Polygon before beginning to support the Sei. In addition to NFT transactions, it offers a variety of features, such as a launchpad.

5.9 Launchpad

• Eclipse Pad — Eclipse Pad is the first launchpad on Cosmos, making it easier for projects in the Cosmos ecosystem to raise funds from the community.

5.10 Payment

• Payment — Sei has a number of onboarded payment services that facilitate on/off-ramp and provide SDKs/APIs. Examples include Kado, Transak, and Payfura.

• Noxx — Noxx is a tool that allows you to pay anonymous employees around the world while complying with regulations and laws.

5.11 Prediction Market / RWA

• Kargo — Kargo is a prediction market protocol that allows you to place bets based on predictions, and anyone can utilize Kargo to host events easily.

• Coded Esate — Coded Estate is a protocol native to the Sei that showcases various features through RWAs that tokenize real-world assets.

• Pharaoh Protocol — The Pharaoh Protocol is a protocol for trading RWAs.

5.12 Incubator / Consulting

• Alpha Venture DAO — Alpha Venture DAO is an incubator specializing in Web3 and ran a 12-week program for DeFi developers with Sei.

• Graviton — Graviton is an India-based accelerator specializing in Web3 projects.

• Airfoil — Airfoil is a design company and incubator for UI/UX design for various Web3 projects.

• MEXC — MEXC, a global cryptocurrency exchange, will operate a $20M fund for the ecosystem of the Sei.

• Stakeme — Stakeme is an incubator where Web3 projects can test their products, expand their testnet, and get development support.

• Wonderstruck — Wonderstruck is an incubator that helps projects with fundraising, deck design, branding, web design, production, UI/UX design, and more.

5.13 Institutions

• Liquidity Alliance — Since many protocols are trying to build order book protocols on top of the Sei’s order matching engine, demand for market making is bound to be high. The Liquidity Alliance is a group of organizations that provide liquidity through market-making to Sei’s native order matching engine. It will significantly improve the user experience by reducing slippage during transactions. As of now, liquidity Alliance includes Skynet Trading, GSR, Kairon Labs, and Flow Traders.

• Zerocap — Zerocap is a provider of institutional professional services in the Web3 space, including liquidity provision, custody, lending, market making, and asset management.

• Rapid Innovation — Rapid Innovation is a dApp development solutions company that provides development solutions to help developers realize your web3 business idea.

6. Conclusion: Beyond Alternative Layer 1 to Alternative Exchanges.

Sei is a layer 1 blockchain with a focus on trading. However, it cannot be classified as an application-specific or sector-specific blockchain, as blockchains are fundamentally financial platforms. Sei appears to view financial infrastructure as the core foundation of blockchain, and by concentrating on this infrastructure, various services can be built upon it. Similar to how real-world countries have progressed through financial advancements, the financial infrastructure that Sei aims to develop will also be beneficial for games and NFTs. Furthermore, Sei has expressed a desire to target the Asian market more than the U.S. market. In its latest funding round, it announced raising funds to increase its influence in the Asian market. It will be intriguing to observe the future impact of Sei in Asia.

In conclusion, the Sei could emerge as a strong competitor to existing centralized exchanges. If it can deliver the same user and trading experiences as centralized exchanges, it will be able to compete with them by leveraging the advantages of blockchain. To date, many users continue to prefer centralized exchanges over decentralized ones due to the latter’s inconvenience. If the Sei can address this issue, it will undoubtedly gain traction as an alternative to centralized exchanges. Although recent developments have been somewhat subdued, the timing is opportune for the Sei, especially given the widespread dissatisfaction with the opacity of centralized exchanges following the FTX debacle. Of course, all of our analysis is based on whitepapers and other documents, so an objective evaluation of the Sei will only be possible once the mainnet is launched. Will the Sei function as intended, unlike other blockchains? This is a question that we eagerly anticipate being answered as the mainnet launch draws near.

Thanks to Kate for designing the graphics for this article.