General-Purpose vs App-Specific L1s


In the beginning, Vitalik created Ethereum. Ethereum expanded upon Bitcoin’s revolutionary distributed ledger by enabling smart contracts to be written and executed directly on-chain. This allowed users to have structured interactions, either with one another or with other smart contracts, and allowed for reliable, deterministic behavior. Crypto Twitter, though still in its infancy, gazed upon Ethereum smart contracts and decided they were good.

Being the first bonafide layer 1 gave Ethereum a huge first-mover advantage. An overwhelming majority of dApps and protocols had to build on Ethereum to leverage its liquidity and user base. In the early years of crypto, it was difficult enough to onboard users to Ethereum, the conditions simply were not favorable for new ecosystems. So for nearly half a decade, dApps and protocols were developed on Ethereum because it was the largest, easiest, and perhaps the only option.

It wasn’t until 2020 that “Ethereum-killers” like Solana, Avalanche, and Binance Smart Chain (BSC) launched their own L1s to compete for Ethereum’s market share. Ethereum had grown too large to support its network traffic. Rising gas prices and latency concerns forced users and developers to seek L1 to improve user experience.

What are “General-Purpose Layer 1s”?

General-purpose L1s are the Swiss Army Knives of Web3 infrastructure. They are blockchains that are not optimized for any specific application, instead, they allow a variety of decentralized applications to be built on top of them. Examples of general-purpose L1s include Ethereum, Solana, Avalanche, and BSC. These chains allow protocols to share (and compete) for users, liquidity, and blockspace.

What are “App-Specific Layer 1s”?

App-specific L1s are blockchains that have been developed exclusively for one or a few decentralized applications. These L1s can customize every aspect of their tech stack, such as their programming language, development frameworks, and consensus mechanisms to best suit their protocol(s) needs. Cosmos Zones are perfect examples of app-specific L1s. These chains are fully customizable and are completely sovereign within their own chains.

Are app-specific L1s new?

The idea of app-specific blockchains has been around for a few years now. However, it has only become widely feasible in the past 2 years thanks to the tech stacks offered by “ecosystems” such as Cosmos and Polkadot. Before their contributions, it was prohibitively complex and labor intensive to build your own L1. Developers would need significant amounts of time and funding to build, market, and interconnect their L1s. New chains would have had to compete with Ethereum and Bitcoin for liquidity in what was essentially a zero-sum game. This made it virtually impossible for any single protocol to attempt to build its own chain.

Why now?

With the advent of Cosmos and Polkadot, the process of building a blockchain has been significantly simplified. Dapps building on Cosmos can utilize the Cosmos SDK as their development framework and the Tendermint core as their consensus mechanism. This abstracts a huge amount of complexity from protocol developers, allowing them to focus on the application layer of their chains.

Another advancement that has significantly propelled the popularity and feasibility of app-specific L1s is the Inter-Blockchain Communication Protocol (IBC). The IBC allows sovereign blockchains within the Cosmos ecosystems to directly communicate and trade assets. This means that users will no longer be limited to the protocols, liquidity, and functionality of just one chain.

Differences between general-purpose and app-specific L1s

Flexibility: App-specific L1s undoubtedly offer more flexibility than their general-purpose counterparts. Developers can customize the programming language, development framework, consensus mechanisms, and technical specifications of their chains.

Simplicity: General-purpose blockchains are easier/less labor intensive for new protocols to launch on. While the Cosmos SDK and Tendermint Core abstract networking and consensus for IBC protocols, app-specific L1s still need to source their own validators which can be a difficult and time-consuming process.

Performance: App-specific L1s typically offer better performance on a per-protocol basis. This is a by-product of the flexibility mentioned above. Chains can be optimized for speed, privacy, transaction volume, and much more. Furthermore, app-specific L1s do not need to deal with congestion stemming from “noisy neighbors”. Without having to compete with NFT mints or other protocols means that transaction speed and cost can remain constant for end users.

Interoperability: IBC chains benefit from specialized interoperability. However, with bridges and interoperability layers such as Axelar, Multichain, and Synapse growing in popularity, both general purpose and app-specific chains will likely experience similar levels of interoperability.

Security: General-purpose blockchains are more difficult to secure, due to the sheer number of possible interactions between every user and protocol on the chain. It is exceedingly difficult to predict and prevent exploits when user behavior is so varied. In general, app-specific blockchains are easier to audit and secure, due to the smaller number of permitted interactions between users can chains.

On a chain level, proof-of-stake general-purpose L1s are more difficult to attack as the sheer amount of capital required is exponentially larger than app-specific chains. However, app-specific L1s may have closed validator sets or entirely novel consensus mechanisms that make them more secure and censorship-resistant.

Is there a middle ground?

As it stands, protocols are still forced to make a difficult decision between building on a general-purpose L1 or creating their own app-specific chain. While most protocols will value the increased performance and flexibility of building their own L1, assembling a validator set and sourcing liquidity for a stand-alone chain can be prohibitively difficult.

As such, even with innovations from the Cosmos and Polkadot teams, many protocols still opt to build on general-purpose chains. Sei has observed that only larger protocols with established user bases, such as dYdX and OKX, are willing to migrate from their “home” chains to Cosmos. These conditions have begun to frame app-specific L1 thesis as a “late game” move instead of an alternative starting point in the eyes of Web3.

Introducing Sei

Sei is the fastest DeFi L1, the fastest chain to finality in Web3, and it aims to change this perception. Sei envisions itself as a DeFi-specific L1 instead of an app-specific chain. This distinction allows Sei to optimize its chain for a class or subset of protocols instead of attempting to create a one-size-fits-all solution.

Sei is a purpose-built L1 that is opening up an entirely new DeFi design space. The team at Sei has thoroughly analyzed the current limitations and pain points of on-chain dApps and protocols to design a true DeFi-specific chain. This novel idea includes optimizations for performance, security, and interoperability.

Performance: One of Sei’s core improvements over competing L1s is its speed. Sei currently offers the fastest Time To Finality (TTF) in Web3, sitting at approximately 600ms. Simply put, TTF measures the time taken between a transaction being submitted to the transaction being confirmed with a guarantee of irreversibility. TTF is analogous to latency as it measures the time taken for information to go from sender → validator → sender.

Security: Sei maintains a focused validator set, which has been rigorously tested throughout Seinami’s incentivized testnet. Protocols building on Sei will be able to leverage Sei’s validators instead of assembling their own validator set. This alleviates one of the largest blockers for migration to Cosmos. Furthermore, Sei utilizes frequent batch auctions to prevent Minimum-Extractable-Value (MEV) from occurring on its chain. Batch auctions are fundamentally less vulnerable to MEV since the ordering of trades within a batch doesn’t affect the price. (Source).

Interoperability: Sei has partnered with Axelar Network to leverage its cross-chain messaging technology. This has enabled Sei to not only bridge assets to and from both IBC and EVM chain, but also to utilize smart contract functionality and logic from all of Axelar’s partners. This allows Sei to interact with users and liquidity from “foreign” chains, greatly expanding the total addressable market for protocols building on Sei.

The goal of Web3 has always been to empower users and developers to interact in optimized and decentralized manners. The current state of the industry prevents new and upcoming protocols to prioritize reach instead of performance. Sei offers a middle ground, where DeFi protocols can build and scale with as few compromises as possible. Sei will unlock an entirely new DeFi design space, enabling existing protocols to grow and novel protocols to be created.


Please enter your comment!
Please enter your name here