Application-specific chains: risks and opportunities – should teams build their own dedicated chain for their application?
TechFlow Selected TechFlow Selected
Application-specific chains: risks and opportunities – should teams build their own dedicated chain for their application?
For some high-growth projects, shifting toward appchains is foreseeable.
Navigating Web3 tides with focused insights
Author: Mohamed Fouda
Compiled by: TechFlow
Over the past year, several high-profile applications have either launched their own dedicated appchains or announced future plans to do so.
For some rapidly growing projects, shifting toward an appchain model is a predictable evolution.
An emerging “Appchain Thesis” predicts that every popular Web3 application will eventually have its own blockchain.
This trend has led some founders to believe that the correct approach is to architect their product as an appchain from day one.
I believe this method may work for certain applications, but for others, investing in an appchain early on could be suicidal.
Why Choose an Appchain?
An appchain is designed primarily to execute a single function or application, such as a game or DeFi platform. This means the application can utilize the chain’s full resources—throughput, state, etc.—without competition from other applications. Additionally, this design allows optimization of technical architecture, security parameters, throughput, and more to precisely match the application’s needs.
Since other applications typically cannot be deployed on the chain, appchains are not necessarily permissionless for developers—they are only permissionless for users.
This contrasts with standard blockchains, where both users and developers are openly accessible.
Appchains as Rural Towns
The analogy of “smart contract chains as cities” helps illustrate the trade-offs founders make when launching an appchain.
General-purpose chains like Ethereum and Solana are like metropolises. They have diverse infrastructure supporting many types of businesses (applications). This makes them more popular, crowded, often more expensive, and sometimes congested.
But this popularity creates significant traffic and opportunity for projects within the ecosystem. Moving between projects is easy, and combining different business activities enables novel and interesting ventures.
In contrast, appchains resemble rural towns centered around a single business activity. The town sets its own rules and policies. It's less crowded and cheaper, but may be less connected to the outside world. Everyone in town uses the same core service, and if it’s unique and popular enough, customers will travel specifically to access it.
This analogy also extends to differences in security and assurance:
- Metro areas have larger, wealthier, and stronger populations. All businesses in the city share a common interest in maintaining a secure and safe environment. These factors make large cities harder to attack—i.e., more secure.
- A rural town’s security is tightly linked to the success and reputation of its single business. If the business thrives, population grows and the town becomes stronger; if it struggles, people leave, weakening security and increasing vulnerability to attacks.
Between these two models lie industry-specific chains that support a subset—but not all—types of applications, such as DeFi or gaming. These are akin to suburban cities: more popular and secure than rural towns, but less busy than metropolises.
General-purpose chains, appchains, and industry-specific chains offer the diversity needed to coexist and serve different use cases. The key is recognizing which scenarios truly require an appchain versus building smart contracts on general-purpose or specialized chains.
When to Use an Appchain?
As we’ve seen over recent years, appchains can be launched for various reasons. In this section, we’ll explore the most common scenarios where building an appchain may be the optimal choice.
Ecosystem Requirements
Builders on ecosystems like Cosmos and Polkadot are essentially required to construct their applications as appchains. Both protocols focus on creating ecosystems of interconnected chains, and neither mainchain implements an execution engine for smart contracts. Therefore, to build any application, one viable path is to launch an appchain or use a chain that provides general computation capabilities.
In the Cosmos ecosystem, chains implementing smart contract execution engines include Evmos (EVM-compatible) and Juno (CosmWasm smart contracts). These general-purpose Cosmos zones host multiple DeFi and NFT applications. Others choose to build optimized appchains—examples include Osmosis (AMM DEX), Mars Hub (lending), and Secret (privacy).
In the Polkadot ecosystem, general computation parachains include Moonbeam (EVM-compatible) and Astar (WASM smart contracts). Examples of appchains on Polkadot include Polkadex (order book DEX), Phala (privacy), and Nodle (IoT network).
Application Requirements
Another scenario where an appchain is optimal is when an application’s throughput or fee requirements cannot be met by general-purpose chains. Applications requiring Web2-level performance in a permissionless Web3 environment should consider an appchain as the primary implementation—games being the prime example.
Most interactive games require extremely high throughput to support real-time user interactions. Moreover, transactions must be free or nearly costless. These demands cannot be satisfied by general-purpose chains, necessitating a dedicated appchain. Notable examples include:
- Axie Infinity — launched on the Ronin sidechain;
- Sorare — a fantasy football game launched on StarkEx L2;
Beyond gaming, DeFi protocols like order book exchanges often require high throughput to deliver superior UX for professional traders. A well-known case is dYdX, a derivatives exchange. dYdX currently processes about 1,000 orders per second. The required chain throughput must exceed 1,000 TPS. For this reason, its V3 was launched as a dedicated Ethereum Rollup using StarkEx technology. As the protocol plans further expansion with even higher throughput needs, it is transitioning to a different appchain implementation—announcing the use of a dedicated Cosmos chain for V4.
Adding Technical Capabilities
If an application requires a specific technology not available on existing L1s, another solution is to build an appchain that implements it. Zero-knowledge proofs (zk-SNARKs or zk-STARKs) are a prime example.
Privacy-focused apps—such as private payments or confidential trading—require ZK proofs as foundational components. However, ZK computations are too intensive and costly to perform directly on-chain. In such cases, the best approach is to implement the required tech on an appchain. Aztec, a privacy-preserving payment and transaction app on Ethereum, launched its L2 for this purpose. A similar example is the Secret appchain in the Cosmos ecosystem.
Improving Application Economics
When a team builds their application as a smart contract on an L1 blockchain, users pay two fees: the native application fee and gas fees.
- The native application fee—for example, trading fees on an exchange or interest spreads in lending—is essentially the app’s revenue stream. This income is typically used to incentivize participants and grow the community, accelerating adoption.
- Gas fees, on the other hand, are paid by users to the L1 validators to ensure transaction inclusion. Gas fees are a cost burden on users, degrading UX. They contribute nothing to the app’s economy and represent economic value leaking out of the application ecosystem. While essential for security, it would be ideal if this value remained within the app’s economy to reward its participants.
Appchains enable this vision. The gas fees and their distribution on an appchain can be controlled to reward the application’s participants.
Yuga Labs’ effort to spin off the Bored Ape Yacht Club (BAYC) ecosystem into a standalone chain exemplifies this scenario. The BAYC community paid massive fees to the Ethereum network during NFT minting. Migrating to their ApeChain will keep those fees within the BAYC economic system.
Why Not Build an Appchain?
Despite their advantages, appchains come with notable risks.
The primary risk is: building an appchain is significantly more complex than developing a smart contract. It requires building infrastructure unrelated to the application’s core business.
Moreover, appchains face increased security and composability risks.
Security
Smart contract applications inherit their security from the underlying L1. As discussed earlier in the metropolis analogy, since the L1 supports multiple applications, its security is maintained by consensus among a large number of participants. This makes L1s more secure and harder to attack. Importantly, L1 security guarantees are independent of any single application’s adoption.
In an appchain, security primarily depends on the application’s adoption and the price of its native token. Depending on implementation, an appchain may use L2 sequencers or independent PoS validators. In both cases, validator rewards are typically denominated in the native app token. Validators must stake the native token and run complex, high-uptime infrastructure to participate. Rewards must outweigh operational costs and token-related risks. Key issues with this model include:
- Staking risks may deter professional validators, attracting amateurs instead, potentially harming network security and uptime.
- Validator rewards tied to token price pressure developers to either inflate token supply or resort to unsustainable gamified tokenomics.
- If adoption and token price remain low, network security weakens, allowing attackers to acquire sufficient stake at low cost to compromise the network.
Cost and Team Time
Launching an appchain requires setting up extensive additional infrastructure and coordinating with validators.
On the infrastructure side, public RPC nodes are needed to allow wallets and users to interact with the chain. Data analytics infrastructure—including block explorers and archive nodes—is required for users to view their activity, along with services like network monitoring and validator dashboards.
The list of required infrastructure is long and demands significant cost and engineering time. A substantial portion of the engineering team ends up handling tasks unrelated to application logic. Maintaining a chain also requires extensive planning and coordination with validators for upgrades or responding to bugs and outages. Governance and community management consume additional resources.
Generally, building an appchain demands larger teams and higher costs—unaffordable for startups, especially in early stages. Diverting focus from core application logic may hinder rapid iteration and achieving product-market fit.
Lack of Composability
One major advantage of building applications as smart contracts is atomic composability. Apps can build on each other, and users can seamlessly interact with multiple protocols in a single transaction. Examples include smart DEX routers that route a single trade across multiple AMMs for optimal pricing, and flash loans that borrow funds from a lending protocol, execute trades or arbitrage on an AMM, and repay—all atomically.
Atomic composability is a unique feature of Web3 that enables novel behaviors and business opportunities. Appchains lack this capability because each app is isolated. Interactions between apps require cross-chain bridges or message passing, which take multiple blocks and cannot be executed atomically. However, this gap creates opportunities for innovative startups to solve the problem.
Cross-Chain Risks
Another issue with appchains is increased risk associated with bridging assets. Specifically, DeFi applications need to bridge multiple assets—BTC, ETH, stablecoins. Cross-chain asset movement degrades UX and introduces greater risk. Cross-chain bridges are frequent targets of exploits; if compromised, DeFi apps relying on bridged assets face bad debt. This risk is even higher for appchains unable to attract reputable, well-capitalized validators. In such cases, appchains may resort to centralized bridges—like centralized exchanges—or build their own.
Opportunities for Appchain Startups
The challenges of the appchain ecosystem create numerous opportunities for startups to provide solutions. Here, we discuss some of them.
1. High-Performance DeFi Protocols
DeFi protocols aiming to compete with Web2 performance must be implemented as appchains. Central Limit Order Book (CLOB) exchanges are ideal candidates. dYdX pioneered this trend, and we expect spot and commodity exchanges to follow, benefiting from low fees and latency. The key driver is customizable tech stacks tailored to DeFi protocol needs.
2. Appchain Gaming Engines
StarkEx is already a popular choice. We expect startups to develop new, efficient architectures for on-chain gaming capable of supporting over 100,000 TPS.
3. Developer Tools for Customizing, Deploying, and Maintaining Sidechains and L2s
Launching a sidechain or rollup with proper architecture to support a specific application is complex. Developer platforms facilitating this process could become highly valuable—think Alchemy for appchains.
4. AI-Powered Appchains
Like zk-proofs, AI is transformative and computationally intensive. Thus, AI-powered applications cannot be built directly on-chain. Many successful Web2 AI products charge high subscription fees. Appchains can democratize access to AI applications.
5. Composability Solutions for Cross-Chain Communication
The lack of atomic composability in appchains creates opportunities for startups to enable cross-chain messaging and simulate composable experiences. Ideas include:
- User-facing frontends that perform cross-chain functions (e.g., IBC transfers or LayerZero messages) in the background, creating the illusion that multiple apps work together compositely—think cross-chain Zapper.
- Wallets with secure multi-chain accounts via MPC that naturally handle cross-chain activities by executing transactions simultaneously across chains—e.g., cross-chain arbitrage.
6. Cross-Chain DeFi Protocols
Despite appchains’ throughput advantages, they fragment liquidity, leading to higher slippage and degraded UX. Cross-chain DeFi protocols that automatically split trades across chains for better pricing will offer improved UX and broader user reach.
7. Trustless Cross-Chain Messaging Between EVM and Non-EVM Chains
A potential way to enhance composability is building universal trustless cross-chain messaging protocols connecting EVM L2s, Cosmos, Polkadot parachains, etc. Such products could replace current bridges and facilitate billions in annual transaction volume.
8. Enabling Cross-Chain Security Sharing
Appchain security challenges can be mitigated by products enabling shared security across chains. Similar to merged mining in PoW chains, we envision methods allowing unrelated PoS chains to share security—e.g., validators securing an appchain using ETH instead of its native token. Liquid staking protocols may play a key role here.
Appchain Implementations
Appchains can be implemented in various ways, differing in complexity and security.
Cosmos
Cosmos was the first ecosystem to envision a world of interconnected blockchains. Based on this vision, Cosmos focused on standardizing and simplifying the process of creating and connecting appchains. This led to the development of the Cosmos SDK—a modular framework for customizing and building blockchains.
The Cosmos SDK was built to default to Tendermint consensus but allows integration with other mechanisms. Later, it was enhanced with the IBC module, enabling trustless communication between Tendermint-based chains—each called a zone. The Cosmos ecosystem now includes over 45 zones, interconnected by more than 700 IBC relayers. Many of these Cosmos zones are single-purpose appchains. One of the largest, Osmosis, is an appchain implementing an AMM DEX.
Cosmos initially embraced isolated security—each zone responsible for its own. Each zone requires a validator set to operate the network, rewarded in the zone’s native token. While flexible, this raises barriers for appchain builders. Hence, Cosmos is implementing a change allowing smaller zones to derive security from the Cosmos Hub via the Interchain Security module.
Polkadot Parachains
Similar to Cosmos, Polkadot also features a multi-chain ecosystem. Chains in Polkadot are called parachains and can be launched using the Substrate SDK.
The key difference between Polkadot and Cosmos is that Polkadot supports shared security from the start—all parachains share security with the main Polkadot chain, known as the Relay Chain.
The Relay Chain’s primary role is to provide consensus and security for parachains. Therefore, it does not implement smart contract functionality.
Due to shared security, Polkadot cannot allow permissionless parachain launches.
Instead, parachain slots are auctioned to developers wanting to build custom chains. Bidding projects must lock DOT. So far, 27 parachains have been auctioned.
Different parachains on Polkadot can communicate via the Cross-Consensus Message (XCM) format. XCM implementation is ongoing and functional but currently requires storing message data on the Relay Chain.
Avalanche Subnets
Avalanche subnets are very similar to Cosmos. Developers can launch their own subnet, each supporting multiple chains, and each subnet requires its own validators.
However, these validators must also validate Avalanche’s primary network in addition to their dedicated subnet.
While this enhances mainnet security, it increases entry barriers for dedicated subnets compared to Cosmos.
Currently, the subnet ecosystem lacks native inter-subnet communication—subnets must build their own bridges. However, the Avalanche team is working to add this functionality to boost subnet adoption.
Ethereum L2s
In Ethereum, the term “appchain” may not accurately describe applications needing a dedicated environment. On Ethereum, such apps can be implemented either as a dedicated L2 or a sidechain. An L2 cannot be considered a true appchain because it doesn’t implement a full tech stack.
- L2s are either Rollups or Validiums, handling only execution and sequencing of transactions. For Rollups, consensus and data availability are provided by Ethereum L1. For Validiums, L1 provides only consensus, while data is stored off-chain. Examples include Sorare and Immutable X.
- The alternative—sidechains—requires launching a separate blockchain validated by a small set of validators for high throughput. A cross-chain bridge connects the sidechain to Ethereum, usually verified by the same validator group. Axie Infinity’s Ronin sidechain is a prime example.
The main advantage of L2s over other approaches is superior security. L2s inherit Ethereum L1 security via zk-proofs or fraud proofs. Despite this, they achieve very high throughput and negligible fees—ideal for gaming apps.
The main drawback of L2s is reduced composability between L2s or between L2 and L1. Fast asset transfers between different Rollups often require third-party providers like LayerZero. While some technologies enable trustless cross-Rollup transfers without going through L1, they incur significant delays—unacceptable for DeFi apps. That’s why DeFi protocols use general-purpose L2s like Optimism and Arbitrum for scaling, rather than app-specific L2s.
Another challenge with L2s is implementation complexity. Compared to the relative ease of launching a Cosmos appchain via the Cosmos SDK, there’s no standard guide for launching an app-specific L2 on Ethereum. However, this may change as Ethereum advances further along its rollup-centric roadmap.
Conclusion
Appchains are gaining attention, but their current development diverges somewhat from the original vision. Implementation of appchains on Cosmos, Polkadot, Avalanche, and Ethereum is trending toward shared security models—with subtle differences. With shared security, appchains don’t truly need their own consensus mechanism.
Instead, applications can simply use a dedicated execution environment serving the app, while relying on the L1 for consensus and data availability. This execution layer could be a Rollup or an independent execution layer following the modular blockchain approach.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Alliance
