DEXs are currently underutilized due to a lack of suitable infrastructure and specific requirements for reliability, scalability, and speed. Sei Network aims to change this by being a sector-specific L1 blockchain specialized in trading, aiming to bridge the performance gap between CEXs and DEXs.

Sei utilizes a unique Twin-Turbo consensus and multiple levels of parallelization to reduce latency and increase throughput. Additionally, Sei offers a native order matching engine and customized user interface, including native price oracles and transaction batching.

Sei Network is built on the Cosmos SDK with the core of Tendermint, to which special features have been added specifically for Sei Network.

The foundation of Sei Network includes:

• IBC (Inter Blockchain Communication) protocol
• Tendermint core
• Cosmos SDK (software development kit)

The IBC protocol enables communication between two or more blockchain networks. IBC is best conceived as the internet that communicates and connects various servers. IBC links entire blockchain networks together,allowing for the creation of an interchain account that remains the same across all blockchain networks supporting IBC. This connection enables staking, trading, or participating in DeFi protocols across multiple blockchain networks from a single point.

All blockchain networks connected to IBC have the Tendermint core. Together with the Cosmos SDK, they form the foundational building blocks of the network. Thanks to these shared foundations, these blockchain networks can communicate with each other seamlessly because IBC takes data from one blockchain, packages it, and unpacks it on another blockchain in the correct format. This communication is possible even across different programming languages, thanks to the shared core.

Twin-Turbo consensus consists of two elements: Intelligent Block Propagation, and Optimistic Block Processing.

Intelligent Block Propagation

Once a full node receives a transaction from a user, it randomly forwards it to other nodes in the network. The validator then verifies the validity of the transaction and adds it to its local memory pool. Block proposers then propose a block containing transaction identifiers and a reference to this block. The block proposal is spread among validators, and the entire block is broadcasted to the network.

If a validator has all the transactions in its local mempool, it reconstructs the block and does not wait for all parts of the block to be delivered. If it doesn't have all the transactions, it waits until it receives all the block parts from the network and then assembles it.

This process reduces the overall time a validator waits for block acceptance. Once all transactions are obtained, validators agree on the transaction order using the Tendermint BFT consensus. The block and corresponding state changes are then written to the blockchain following the preceding voting and commit steps.

Optimistic Block Processing‍

In Tendermint consensus, validators receive a block proposal, verify its validity, and proceed with a pre-vote. Instead of waiting for transaction processing until the precommit step, validators start the process in parallel to optimistically process the first block proposal for any height. Optimistic block processing writes the candidate state to the cache.

If the block is accepted by the network, the data from the cache is sent. If the block is rejected, the data from the cache is discarded, and optimistic processing is not used for that height in the future.

The theoretical improvement in latency due to optimistic block processing depends on the Tprevote and Tprecommit times (latency before voting and sending), the number of transactions N, and the average latency of a single transaction T.

Parallelism

During block processing, validators execute the BeginBlock, DeliverTx, and EndBlock logic within the Cosmos SDK framework. Sei has configured the DeliverTx and EndBlock functions to parallelize transaction processing. In the DeliverTx phase, all transactions in the block are processed, resulting in state changes. Transactions related to the central order book undergo basic processing in DeliverTx, and most state changes are applied during the EndBlock logic. Parallelization has been implemented in both DeliverTx and EndBlock to achieve optimal performance.

Transaction Parallelization:

To prevent race conditions and non-determinism, Sei maintains a mapping of transaction message types to keys they need access to. Transactions with different keys can be executed in parallel, while transactions with the same key are executed sequentially in a deterministic order. Before executing transactions, dependencies between them are identified using a directed acyclic graph (DAG).

Sei allows defining dependency mappings as templates that are filled at runtime, providing flexibility for parallel processing. Smart contracts can define their own dependencies on resources, enabling their parallel processing and reducing gas fees. Improperly defined dependencies may result in message failures for a given smart contract but won't affect the overall network.

Price Oracles

Sei Network ensures the valuation of assets and exchange rates through price oracles using validator voting. Validators provide their proposals for exchange rates during a specific voting window, and at the end of the voting period, a weighted median of the votes is calculated, determining the actual exchange rate. Penalties are imposed for non-participation and participation with incorrect data. Validators are monitored, and if they have a high number of missing data, their position is reduced as a punishment.

Order Matching Tool

Sei Network provides an order comparison and matching tool called a "matching engine," which is utilized by exchanges built on Sei. This engine allows decentralized exchanges to deploy their own order books and provides functionality for market creation and trading. Creating a new order book requires two transactions: deploying a smart contract into the Sei system and sending a transaction to add a new order book with specified parameters.

The matching engine supports various order types, including limit orders, market orders, fill-or-kill orders, stop-loss orders, and order cancellations. Partial execution of an order is possible for limit, market, and stop-loss orders if there is insufficient liquidity to execute the entire order.

Order Lifecycle

The order lifecycle in the Sei Network is atomic and involves transactions related to the Central Limit Order Book (CLOB) and the matching mechanism. All transactions related to the CLOB are executed atomically within a block. The matching mechanism processes orders and adds them to the internal state, called MemState, of the dex module. After block processing, the EndBlocker hook is used to aggregate orders and invoke the smart contract for the specific market. The smart contract implements its own logic and calls the matching engine.

The matching engine first processes limit orders and then market orders, ensuring maximum liquidity. Limit orders are filled at the best price, and if there is insufficient liquidity, orders with a larger slippage are prioritized. Finally, all unfilled orders expire. The entire process is governed by smart contracts, which ensure the settlement of assets.

Order Aggregation

Sei Network provides order aggregation layers that improve user convenience and performance. Transactions on the Sei platform can contain orders targeting multiple trading markets. During block processing, these orders are correctly routed to the respective smart contracts, reducing gas costs associated with updating market maker positions. Sei also aggregates orders across transactions at the chain level, allowing for the operation of a single instance of a virtual machine and reducing latency by up to 1 ms per order.

Frontrunning

Sei Network and its Matching Engine for order comparison utilize frequent batch auctions to execute trades. This approach brings several advantages for users.

The first advantage is ensuring price fairness. Sei's Matching Engine collects orders and conducts an auction where orders are filled based on a specified time interval. This minimizes information asymmetry among market participants and ensures that trades are executed fairly at reasonable prices.

The second advantage is the prevention of frontrunning. Frontrunning is an unfair practice where someone exploits information about another participant's planned trades and executes their own trades to influence the market price in their favor. The use of batch auctions reduces the risk of frontrunning because orders are executed simultaneously within the auction, and participants do not have advance access to information about individual trades.

Participation in the Sei Network testnet needs only a wallet supportive of the network. We recommend using the Keplr wallet, which you can download here. Next, visit the faucet page, where you can request an initial supply of tokens to operate on the Sei Network. For further useful information about the Sei Network ecosystem, please visit this site. This page represents an exhaustive list of all projects already running on the Sei Network.