The Appchain Universe: The Risks and Opportunities

Over the past year, several high-profile applications have launched their own application-specific chain or announced plans to do so in the future. This appchain direction was predictable for a number of high-growth projects. The appchain thesis predicted that every popular Web 3 application will eventually have its own blockchain. The trend makes some founders think that the right course of action is to architect their product from the beginning as an appchain. We believe that this approach may work for some applications. Other applications will be shooting themselves in the foot by investing in building an appchain early on.

This is one of the topics that we discuss often within the Alliance founder community. From these discussions, we have identified a number of scenarios where appchains can be the best approach. In addition, we have identified gaps that need to be addressed and startup opportunities for strong founders.

At Alliance, we are looking forward to working with teams building these solutions. If you are a founder building a startup in this domain, please reach out and join our community where we can support you.

Why appchains?

Appchains are designed to primarily perform a single functionality or application e.g., a game or a DeFi application. That means that the application can use the full resources of the chain, e.g., throughput, state, etc, without competition from any other applications. Furthermore, this design choice allows optimizing the chain technical architecture, security parameters, throughput, etc to match the application needs. As it is not often possible to deploy other applications to the chain, appchains are not necessarily permissionless for developers to build on, they are permissionless only for users to use. The appchain concept is a departure from the standard blockchain practice where the chain is open for both users and developers.

Appchains as rural towns

The notion of smart contract chains as cities is useful to explain the compromise founders take in launching their applications as appchains. General purpose computing chains such as Ethereum and Solana act like metropolitan cities. They have a diverse infrastructure to support different kinds of businesses (apps). That makes the general-purpose chains more popular, more crowded, generally more expensive, and sometimes hectic. But this popularity creates a lot of traffic and opportunities for businesses in the ecosystem. It’s easy to go from one business to another. It’s also possible to combine different business activities to create new interesting businesses.

On the other hand, appchains act like rural towns that have single business activity. The town can create its own rules and policies. It is less crowded and cheaper but may not be well-connected to the external world. The town’s single business is used by everyone in the town. Customers may even come to this town for this specific business if it is popular and unique enough.

The analogy also extends to describe the difference in safety and security between the two scenarios. Large cities are more populous, wealthier, and stronger. There is a shared interest from all the city’s businesses to have a safe and secure city. These factors make large cities harder to attack, i.e., more secure. On the other hand, a rural town’s security is tightly coupled to the popularity and success of its single business. If the business is doing well, the number of town residents increases and the town becomes stronger, if the business is struggling, people leave making the town less secure and easier to attack.

In the middle between these two models lies sector-specific chains. Chains that support some but not all businesses, e.g., DeFi or gaming. Sector-specific chains are equivalent to suburban cities which can be more popular and safe than rural towns but less hectic than metropolitan cities.

General compute chains, appchains, and sector chains offer needed diversity and can co-exist and address different needs. What is important is to recognize which use cases require appchains versus building smart contracts on a general-compute chain or a sector chain. The first part of the article discusses the appchain thesis and when to use an appchain. The second part covers the startup opportunities that exist in that universe. The last part compares the different appchain implementation approaches.

When to use an appchain?

Appchains can be started for various reasons as we have seen in the last couple of years. In this section, we discuss the most common scenarios where building an appchain can be the best option.

Ecosystem requirement

Application builders on ecosystems such as Cosmos and Polkadot are essentially required to build their applications as appchains. Both protocols focus on building an ecosystem of multiple interconnected chains. The main chain in either ecosystem does not implement an execution engine to support smart contracts. Hence, to build any application, the possible ways are either building an appchain or using a chain that implements a general compute execution engine.

In the Cosmos ecosystem, examples of ecosystem chains that implement a smart contract execution engine include Evmos (EVM compatible) and Juno (CosmWasm smart contracts). Each of these general-purpose cosmos zones has several DeFi and NFT applications. Other applications opt to build their optimized appchains. Exampled include Osmosis (AMM DEX), Mars hub (lending), and Secret (Privacy).

In the Polkadot’s ecosystem general compute 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 when building an appchain is the best approach is when the application throughput requirements or fee requirements cannot be met by a general compute chain. Applications that require Web 2 performance in a permissionless Web 3 environment should consider appchains as the first implementation option. Gaming applications are the best example of this category. The majority of interactive games require extremely high throughput to support users’ game interactions. Moreover, these transactions should be free or cost negligible fees. These requirements cannot be met using general compute chains and require launching a dedicated appchain. A few examples include:

• Axie Infinity game — launched on the Ronin sidechain
• Sorare — a fantasy football game launched as a StarkEx L2

Outside of gaming, DeFi protocols such as order book exchanges often require high throughput to deliver superior UX for professional traders. A known example is the DeFi derivative exchange dYdX. The dYdX protocol currently processes ~ 1000 order placements per second. The required chain throughput should exceed 1000 TPS. For this reason, the protocol’s V3 was launched as a dedicated Ethereum rollup based on the StarkEx technology. As the protocol plans for further scaling that requires higher throughput, it is shifting into a different appchain implementation. The protocol announced it will use a dedicated Cosmos chain for its V4.

Adding technological features

If the application requires a specific technology that is not available on the L1 chain, the alternative is to build an appchain that implements this technology. The best example of that is zero-knowledge proofs such as zk-Snarks or zk-Starks. Privacy-focused applications such as private payments or private trading require zk proofs as a building block. However, generating zk proofs is computationally intensive and these computations are too expensive to be performed on-chain. The best approach, in this case, is to implement the required technology on an appchain. Examples of this approach include Aztec, a privacy maintaining payment and trading application on Ethereum. Aztec has launched its L2 on Ethereum for this purpose. A similar example is the Secret appchain on the Cosmos ecosystem.

Improving the application economics

When a team builds their application as a smart contract on an L1 blockchain, the application users pay two kinds of fees to the application: native application fees and gas fees. The native application fees, e.g., trading fees for exchanges or spreads for lending protocols, are essentially the application revenue stream. This revenue is often used as incentives for the application participants to grow the application’s community and accelerate the adoption of the application. On the other hand, gas fees are paid by the application users to the validators of the L1 to ensure that their transactions are included. Gas fees are overhead to the application users and degrade the user experience. The gas fees do not contribute to the economy of application and represent a lost economic value extracted from the application and paid to the hosting L1 in the form of rent. Although this rent is essential to ensure the security of the application, a more optimal scenario would be if this economic value stays in the application’s economic system to reward the application participants. Appchains enable this scenario. The appchain’s gas fees and their distribution can be controlled to reward the application’s participants. Yuga Labs’s efforts to spin out the Bored Ape Yacht Club (BAYC) ecosystem as a separate chain is the best example of that scenario. The BAYC community paid huge fees to the Ethereum network during the mint of the project’s NFTs assets. The community still pays fees significant for the trading of these assets to the Ethereum network. Moving to their ApeChain will keep these fees in the BAYC’s economic system.

Why not to build an appchain

Despite the several advantages of appchains, some risks need to be taken into consideration. The main risk is that building an appchain is significantly more complex than developing a smart contract. It requires the development of infrastructure that is not related to the application’s core business. In addition, the appchain has increased security and composability risks.

Security guarantees

Smart-contract applications draw their security from the underlying L1. As discussed earlier in the metropolitan city analogy, as the L1 supports several applications, the incentive to keep the L1 secure is shared between a large number of L1 participants. That makes the L1 more secure and harder to attack. Further, the L1 security guarantees are independent of the adoption of a specific application.

In appchains, the security largely depends on the adoption of the application and the price of the application’s native token. Depending on the implementation details, the appchain can be either L2 sequencers or independent PoS validators. In both cases, the validator incentives are often denominated in the native application token. The validators have to stake the native token and operate sophisticated infrastructure with high uptime to participate in the network. The validation reward needs to be higher than the operating cost and the token exposure risk that validators are taking. Some issues with this model include:

1. The staking exposure risks can complicate attracting professional validators to the network and instead attract hobbyist validators which can compromise the network security and uptime.
2. The validator rewards dependence on the token price adds pressure on application developers to either use high token inflation or use gamified token economics that are not sustainable.
3. If the application adoption is weak and the token price is low, the network security becomes weak enabling malicious parties to acquire enough stake to attack the network at low cost.

Cost and team time

Launching an appchain comes with a long list of additional infrastructure that needs to be built and activities that be coordinated with validators. On the infrastructure side, public RPC nodes are needed to allow wallets and users to interact with the chain. Data analytics infra including a block explorer and archival nodes are also needed to allow users to view their activity. Services such as network monitoring and validator information are also needed. The list of the needed infrastructure is long and requires significant costs and engineering time. A considerable part of the engineering team will be tackling tasks unrelated to the application logic. Moreover, maintaining a chain requires significant planning and communication with the validators to arrange for network upgrades or to respond to bugs and network downtime. Governance and community management also require a lot of resources from the application team.

In general, building an appchain will require a larger team and increased costs that startups cannot afford especially in the early stage. The distraction away from the core application logic can become a hurdle for the application to adapt quickly and achieve a product market fit.

Lack of Composability

One of the main advantages of building applications as smart contracts is atomic composability. Applications can build on each other and users can seamlessly interact with multiple protocols in the same transaction. Examples of that include smart DEX routers that can route a single trade through different AMMs to achieve the best pricing. Another example is flash loans where a transaction can borrow from a lending protocol and execute a trade or an arbitrage on AMMs before paying back the loan. These interactions can happen atomically within the same transaction. Atomic composability is a unique feature in Web 3 applications that enable interesting behaviors and business opportunities. Appchains lack this atomic composability because each application is isolated from the rest. Interactions between applications require cross-chain bridging or messaging which requires several blocks and cannot be done atomically. However, this lack of atomic composability can give rise to some interesting startups that solve this issue. Examples include:

Bridging Risk

Another issue with appchains is the increased risk of bridged assets. DeFi applications in specific require bridging of several assets such as BTC, ETH and, stablecoins. The bridging of assets degrades the user experience and carries a larger risk. Bridges are common targets for exploitation and can leave DeFi applications that use the bridged assets with bad debt if the bridge is compromised. The risk is even higher for appchains that may not be able to attract reputable and well-funded bridges. In these scenarios, appchains might resort to use centralized bridges such as centralized exchanges or develop their own bridges.

Appchain startup opportunities

The challenges of the appchain ecosystem creates several opportunities for startups to solve. Here we discuss a number of these opportunities. We encourage founders working on or interested in building these solutions to reach out.

1. High performance DeFi protocols

DeFi protocols that aim to compete with Web 2 performance need to be implemented as appchains. Central Limit Order Book (CLOB) exchanges are the top candidates for this. dYdX derivatives exchange started this trend and we expect to see spot and commodity exchanges to be built as appchains to benefit from low fees and low latency. The key enabler here to work with a customizable technology stack that can adjusted to the DeFi protocol needs.

2. Appchain gaming engines

One of the gaps that limit the adoption of appchains for performance-constrained applications, such as gaming is the limited implementation options. StarkEx is a popular option in this regard. We hope to see startups that build new efficient architectures that can support 100K+ in TPS for onchain games.

3. Developer tooling to customize, deploy and maintain sidechains and L2s

It’s a complex task to launch a sidechain or a rollup with the proper architecture to support a specific application. A developer platform that facilitates this task can become a very valuable business, think Alchemy for appchains.

4. AI-enabled appchains

Similar to zk proofs, AI is transformative technology that is also computationally intensive. Hence, AI-enabled applications cannot be built onchain. There are many successful web 2 AI products that require users to pay large subscription fees. Access to AI applications can be opened to the public using appchains. Consider building applications that run trained AI models, e.g., Dall-E or GPT3, that are open to the public to use.

5. Composability solutions that abstract cross-chain communication

The lack of atomic composability in appchains creates opportunities for startups to abstract the crosschain messaging and create a perceived composability. Ideas here include:

• User front ends that perform cross-chain functionalities under the hood, e.g., IBC transfers or LayerZero messaging, and create the illusion that several appchains work in a composable fashion. Think cross-chain zapper.
• Wallets that implement secure multichain accounts via multi-party computing (MPC) and that natively handle cross-chain activities by performing simultaneous transactions on multiple chains. An example use case is cross-chain arbitrage.

6. Crosschain DeFi protocols

Despite the several advantages of appchains in terms of throughput, they also lead to fragmented liquidity which leads to increased slippage and degraded UX. Cross-chain DeFi protocols that automatically split trades between different chains for better pricing will have better UX and larger customer base.

7. Trustless cross-chain messaging between EVM and non-EVM chains

Appchain implementations are split between Cosmos, Polkadot and EVM L2s. A possible approach to improve composability is to build generalized trustless crosschain messaging protocols that can connect EVM L2s, Cosmos zones, polkadot parachains, etc. Such a product can replace existing bridges and facilitate billions of dollars of volume annually.

8. Enabling cross-chain security sharing

The security challenges of appchains can be mitigated using products that enable cross-chain security. Similar to merged mining for PoW chains, we envision approaches that can allow shared security between unrelated PoS chains, e.g, Validators staking ETH instead of the native appchain token to secure the appchain. Liquid staking protocols may probably play an important role in this regime.

Appchain Implementation

Appchains can be implemented in multiple ways that differ in complexity and security. This section briefly compares a few options that facilitate the appchain implementation.

Cosmsos Zones

Cosmos is the first ecosystem to envision a world of multiple interconnected blockchains. Based on this vision, the cosmos development has focused on standardizing and simplifying the process of launching dedicated chains that can be interconnected together. This work has resulted in the Cosmos SDK which is a modular framework to customize and develop blockchains. The cosmos SDK was built to support the Tendermint consensus mechanism by default but allows the use of other consensus mechanisms. The Cosmos SDK was later improved by adding the IBC module which allows trustless communication between Tendermint-based chains. Each of these chains is called a Zone. The Cosmos ecosystem has grown to more than 45 zones interconnected by more than 700 IBC relayers. Many of these Cosmos Zones are appchains that serve a single purpose. One of the largest Cosmos zones, Osmosis, is an appchain that implements an AMM DEX.

Cosmos has initially adopted the philosophy of segregated security, i.e., each zone is responsible for its own security. Each zone needs to recruit a validator set to operate the network and reward this validator set with the Zone’s native token. Despite the flexibility of this approach, it increases the barrier of entry for appchain builders and takes away their focus to engage and recruit validators. Hence, Cosmos is implementing a change that will allow smaller Zones to recruit security from the Cosmos hub through Interchain Security Module.

Polkadot Parachians

Similar to Cosmos, Polkadot fosters a multichain ecosystem. The chains in the Polkadot ecosystem are called Parachains and they can be launched using the Substrate SDK. The main difference between Polkadot and Cosmos is that Polkadot has subscribed to a shared security vision from the beginning. All the parachains share security with the main Polkadot chain, called the Relay Chain. The Relay Chain’s main function is to provide consensus and security to the Parachains. Hence, the Relay Chain doesn’t implement smart contract functionalities. Because of the shared security guarantee, the Polkadot ecosystem cannot allow parachains to launch without permission. Instead, parachain slots are auctioned to developers who want to build a custom chain. The competing bidders have to lock DOT, to secure a parachain slot. There have been 27 auctioned parachains so far.

The different parachains on Polkadot can communicate via Cross Consensus Messaging (XCM) format. The implementation of XCM communication is in progress and is currently functional but requires the storage of the messaging data to the Relay Chain.

Avalanche Subnets

Avalanche’s implementation of Subnets is very similar to the Cosmos approach. Developers can launch their own subnets and each subnet can support multiple chains. The subnets need to recruit their own validators. However, these validators need to both validate the Avalanche’s Primary Network, in addition to validating the dedicated subnet. Although this requirement increases the security of the Primary network, it increases the barrier of entry for dedicated subnets compared to Cosmos.

Currently, the subnet ecosystem doesn’t support native inter-subnet communication and subnets have to develop their own bridges. The Avalanche team is however working to add this functionality to increase the adoption of subnets.

Ethereum L2s

In Ethereum, the term “appchain” may not be always accurate to describe applications that need a dedicated environment. In Ethereum, such applications can either be implemented as a dedicated L2 or as a sidechain. The L2 implementation cannot be called an appchain, because it does not implement the complete chain stack. L2s are either rollups or validiums that just perform execution and ordering of transactions. For rollups, consensus and data availability are provided by the Ethereum L1. For validiums, the L1 just provides consensus, the data are stored off-chain. Examples of applications that use this architecture include Sorare and Immutable X.

The other approach, i.e., sidechain, requires launching an independent blockchain that is validated by a small number of validators to enable high throughput. The sidechain is bridged to Ethereum with a bridge that is often validated by the same group of validators. The known example of that is the Ronin sidechain that supports the Axie Infinity game.

The main advantage of the L2 implementation approach is its superior security guarantees compared to all other approaches. L2s inherit security from the Ethereum L1 via zk Proofs or fraud proofs. Still, they can achieve very high throughput and negligible fees. These requirements fit well the needs of gaming applications. The main disadvantage of the L2 approach is that composability is even harder between L2s or between the L2 and L1. Quick transfer of assets between different rollups often requires third-party providers such as LayerZero. Although there are some techniques to transfer assets trustlessly between rollups without passing through L1, these techniques require significant delays that cannot be tolerated by DeFi applications for example. That is why DeFi protocols use general-purpose L2s such as Optimism and Arbitrum as a scaling mechanism instead of application-specific L2s.

Another challenge of using the L2 approach is the complexity of implementations, compared to the relative simplicity of launching a Cosmos appchain using the Cosmos SDk, there is no standard playbook on launching application-specific L2s on Ethereum. However, this may change in the future as Ethereum goes further in its rollup centric roadmap.

Conclusion

The appchain thesis is gaining traction but is developing into a direction that is different from what was originally envisioned. The implementations of appchains on Cosmos, Polkadot, Avalanche, and Ethereum are converging to a shared security approach with minor differences. With shared security, appchains do not really need a consensus mechanism. Instead, applications can just use a dedicated execution environment that serves the application and that uses an L1 for consensus and data availability. This execution environment can either be a rollup or an independent execution layer that follows the modular blockchain approach.