This article discusses the risks and opportunities of application chains such as Cosmos and Polkadot

Note: The author of the original article is Mohamed Fouda, a partner at Volt Capital.

Over the past year, some high-profile apps have launched their own specific Lisk chains or announced related plans. For many high-growth projects, Lisk’s direction is predictable. The Lisk theory predicts that every popular Web 3 application will eventually have its own blockchain. This trend has led some founders to believe that the right thing to do is to build their product as a Lisk from the start. We believe that this approach may work for some applications, while others will struggle if they build an application chain early on.

This is one of the frequently discussed topics in our affiliate founders community. Through these discussions, we have identified some scenarios where Lisk might be the best approach. Additionally, we identified gaps that need to be addressed and entrepreneurial opportunities for great founders.

This article discusses the risks and opportunities of application chains such as Cosmos and Polkadot

Why choose Lisk?

Lisk is designed to primarily execute a single function or application, such as a game or DeFi application. This means that applications can use the full resources of the blockchain, such as throughput, state, etc., without competing with any other applications. Furthermore, this design choice allows optimizing the technical architecture, security parameters, throughput, etc. of the blockchain to match the needs of the application. Lisks are not necessarily permissionless for developers as it is generally not possible to deploy other applications on the blockchain, they are only open for use by users. From this perspective, the concept of Lisk differs from standard blockchain practice, where the blockchain is open to both users and developers.

Application chain analogy to rural towns

The concept of a smart contract chain as a city helps explain the compromises founders made when launching their application as an Lisk. General computing chains like Ethereum and Solana are like metropolises, they have diverse infrastructure to support different types of businesses (applications). This makes general-purpose blockchains more popular, more crowded, often more expensive, and sometimes busy. But this approach creates a lot of traffic and opportunity for businesses in the ecosystem.

Lisk, on the other hand, behaves like a rural town with a single commercial activity. The town can make its own rules and policies, it’s less crowded and therefore cheaper, but probably doesn’t have a good connection to the outside world. Everyone in town uses a single business in town, and if it’s popular and unique enough, customers might even come to town for that particular business.

The analogy also extends to describe the security differences between the two scenarios. Big cities are more populated, wealthier, and more powerful, and all businesses in the city have a common interest in having a safe and secure city. These factors make large cities harder to attack (ie, safer). On the other hand, the safety of a country town is closely related to the popularity and success of its single business. If business is good, the number of inhabitants of the town will increase and the town will become stronger, and if business is bad, people will leave, which makes the town less secure and more vulnerable to attack.

In the middle of these two models are industry-specific blockchains that support some but not all businesses (such as DeFi or gaming). Industry-specific blockchains are the equivalent of suburban cities, which are more popular and safer than rural towns, but not as prosperous as big cities.

This article discusses the risks and opportunities of application chains such as Cosmos and Polkadot

Universal computing chain, application chain and industry chain provide the required diversity, they can coexist and meet different needs. It is important to recognize which use cases require application chains rather than building smart contracts on general computing chains or industry chains.

The first part of this article discusses the topic of Lisk and when to use Lisk, the second part introduces the entrepreneurial opportunities that exist in the field, and the last part compares different Lisk implementation approaches.

Why should an application use an application chain?

As we have seen over the past few years, project parties can launch Lisk for various reasons. In this section, we will discuss the best possible common scenarios for building Lisk.

Ecosystem Requirements

Application builders on ecosystems like Cosmos and Polkadot basically need to build their applications as Lisks. Both protocols focus on building an ecosystem of interconnected blockchains. The main chains in both ecosystems do not implement an execution engine that supports smart contracts. Therefore, to build any application, the possible approach is to build an application chain or use a blockchain that implements a general-purpose computational execution engine.

In the Cosmos ecosystem, examples of ecological chains that implement smart contract execution engines, including Evmos (EVM compatible) and Juno (CosmWasm smart contracts). Each of these general-purpose Cosmos zones has multiple DeFi and NFT applications. Other applications will choose to build their optimized application chain, examples include Osmosis (AMM DEX), Mars hub (lending) and Secret (privacy).

In the Polkadot ecosystem, general computing parachains include Moonbeam (EVM compatible) and Astar (WASM smart contracts), and examples of application chains on Polkadot include PolkaDex (order book DEX), Phala (privacy), and Nodle (Internet of Things network) .

Application Requirements

Another case for building an application chain is when a general-purpose computing chain cannot meet the throughput requirements or cost requirements of the application, which would be the best approach. Applications implementing Web 2-level performance in a permissionless Web 3 environment should consider application chains as a first implementation option. And games are the best example of such an application. Most interactive games require extremely high throughput to support user interaction with the game. Also, these transactions should be free or with negligible fees. These requirements cannot be met by using a general-purpose computing chain, and the game needs to start a dedicated application chain. Some examples include:

  1. Axie Infinity games launched on the Ronin sidechain;
  2. Sorare’s fantasy football game in the form of StarkEx L2;

Beyond gaming, DeFi protocols such as order book DEXs often require high throughput to provide a superior user experience for professional traders. DeFi derivatives exchange dYdX is a known example. The dYdX protocol currently processes around 1000 orders per second and its required blockchain throughput should exceed 1000 TPS. As such, the V3 version of dYdX was launched as a dedicated Ethereum rollup based on StarkEx technology. As the dYdX protocol plans to scale further (requiring higher throughput), it is moving to a different Lisk implementation, having previously announced that the V4 version will use a dedicated Cosmos Lisk.

Add technical features

If an application requires a specific technology that is not available on the L1 chain, another approach that can be taken is to build an application chain that implements that technology. The best examples are zero-knowledge proofs such as zk-Snarks or zk-Starks. Privacy-conscious applications like private payments/transactions require zk proofs as building blocks. However, generating zk turns out to be computationally intensive, and these computations are too expensive to perform on-chain. In this case, the best approach is to implement the required technology on Lisk. Examples of this approach include Aztec, which launched L2 on Ethereum, and similar examples, the Secret Lisk in the Cosmos ecosystem.

Improve application economics

When a team builds their application as a smart contract on the L1 blockchain, users of the application pay two fees: the application fee and the gas fee. Fees for the application, such as transaction fees with DEXs or spreads on lending protocols (essentially the source of revenue for the application). This revenue is typically used to incentivize app participants to grow the app community and accelerate app adoption.

On the other hand, users of the application pay L1 validators gas fees to ensure that their transactions are included in the blockchain. Gas fees are an overhead for app users, which degrades user experience. Gas fees do not contribute to the economics of the application and represent the loss of economic value extracted from the application and paid to hosting L1 in the form of rent. While this rent is critical to ensuring the security of the application, it would be more ideal if this economic value was left in the application’s economic system to reward application participants. The application chain supports this scenario, and can control the gas cost of the application chain and its distribution to reward the participants of the application. Yuga Labs’ separation of the Boring Ape (BAYC) ecosystem as a separate chain is the best example of this situation. The BAYC community pays huge fees to the Ethereum network during the minting of the project’s NFT assets. If the application continues to be hosted on Ethereum, the community needs to continue to pay a lot of fees to the Ethereum network, and migrating to their own ApeChain, can Keep these fees in BAYC’s economic system.

Why you shouldn’t build an application chain

Although Lisk has several advantages, we also need to consider some risks. The main risk is that building an application chain is much more complex than developing smart contracts, which requires developing infrastructure that is unrelated to the application’s core business. In addition, the application chain is weaker than the general smart contract chain in terms of composability and security.


Smart contract applications derive their security from the underlying L1, and as discussed earlier in the metropolitan analogy, since L1 supports multiple applications, the motivation to keep L1 secure is shared among a large number of L1 participants. This makes L1 more secure and harder to attack. Furthermore, L1’s security guarantees are independent of application-specific adoption.

In Lisk, however, security largely depends on the adoption of the application and the price of the application’s native token. Depending on the implementation details, Lisk can be an L2 sequencer or a standalone PoS validator. In both cases, validator rewards are usually denominated in application tokens. Validators must stake native tokens and run complex infrastructure with high uptime requirements to participate in the network, in addition, validation rewards need to outweigh the operational cost and token risk borne by validators. Some problems with this model include:

  1. Staking risk can complicate attracting professional validators to the network and instead attract amateur validators, potentially jeopardizing network security and uptime.
  2. The reliance of validator rewards on token prices increases the pressure on app developers to either adopt a highly inflationary token economy or an unsustainable gamified token economy.
  3. If application adoption is low and token prices are low, the security of the network is weakened, which allows malicious parties to gain enough stake to attack the network at low cost.

Cost and team time

Launching a Lisk chain comes with a long list of infrastructure to build and activities to coordinate with validators. In terms of infrastructure, public RPC nodes are required to allow wallets and users to interact with the blockchain. In addition, data analysis infrastructure is required, including blockchain browsers and archive nodes to allow users to view their activity, services such as network monitoring and validator information are also required, all in all, the infrastructure required to launch Lisk The list is long and requires a lot of cost and engineering time. That said, the application engineering team needs to solve a large number of tasks that are not related to application logic. Additionally, maintaining the blockchain requires communication with validators to schedule network upgrades or respond to vulnerabilities and network downtime. That said, governance and community management also require a lot of resources from the application team.

Generally speaking, building a Lisk will require a larger team and increase costs that startups cannot afford (especially in the early stages). A distraction from core application logic can be a barrier to rapid application adaptation and product-market fit.

lack of composability

One of the main advantages of building applications based on smart contract chains is atomic composability. Applications can build on each other, and users can seamlessly interact with multiple protocols in the same transaction. Examples of these include smart DEX routing, where users can make a single transaction through different AMMs to achieve the best price. Another example is a flash loan, where one can borrow from a lending agreement and carry out an arbitrage trade on AMMs before the loan is repaid. These interactions can occur within the same transaction. Atomic composability is a unique feature in Web 3 applications that enables interesting behaviors and business opportunities.

Lisk lacks this atomic composability because each application is isolated from the others. Interactions between applications need to be passed across chains, which requires several steps and cannot be done atomically. Of course, this lack of atomic composability will also attract some interesting startups to tackle the problem.

Cross-chain risk

Another problem with Lisk is that the risk of cross-chain assets increases. Specifically, DeFi applications require cross-chain multiple assets, such as BTC, ETH, and stablecoins. And cross-chain will reduce the user experience and bring greater risks. Cross-chain bridges are also frequently targeted by hackers. If cross-chain bridges are attacked, related DeFi applications may have bad debts. The stakes are even higher for Lisks that may not be able to attract reputable and well-funded cross-chain bridges. In these cases, Lisk may turn to a centralized cross-chain bridge, such as a centralized exchange or develop its own cross-chain bridge.

Lisk Startup Opportunities

The challenges of the application chain ecology also provide some opportunities for start-ups. Here, we discuss many of these opportunities. We encourage founders who are committed or interested in building these solutions to reach out.

1. High-performance DeFi protocol

DeFi protocols designed to compete with Web 2 performance need to be implemented as Lisks. Central Limit Order (CLOB) exchanges are the go-to for this, a trend dYdX pioneered, and we expect spot and commodity exchanges to be built as Lisks to benefit from low fees and low latency. The key enablers here can use a customizable technology stack that can be tuned to DEFI protocol needs.

2. Application chain game engine

One of the gaps limiting the adoption of appchain for performance-constrained applications such as games is limited implementation options. In this regard, StarkEx is a popular choice. We hope to see some startups build new efficient architectures to achieve 100,000+ TPS for on-chain games.

3. Developer tools for customizing, deploying and maintaining sidechains and L2

Launching a sidechain or rollup with the proper architecture to support a specific application is a complex task. A developer platform that facilitates this task can be a very valuable business, think Alchemy of Lisk.

4. Application chain supporting artificial intelligence (AI)

Similar to zero-knowledge proofs, artificial intelligence (AI) is a computationally intensive and transformative technology. Therefore, AI-enabled applications cannot be built on-chain. 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 Lisk. Consider building an application that runs a trained AI model, such as Dall-e or GPT3, and then making it available to the public.

5. The composability solution abstracts cross-chain communication

The lack of atomic composability in Lisk creates an opportunity for startups to abstract cross-chain messaging and create perceived composability. Ideas here include:

  1. The user frontend performs cross-chain functions in the background, such as IBC transfers or LayerZero messaging, and creates the illusion that several application chains are working in a composable way. Think of a cross-chain version of zapper.
  2. A wallet that implements secure multi-chain accounts via Multi-Party Computation (MPC) and natively handles cross-chain activity by executing simultaneous transactions on multiple chains. An example use case is cross-chain arbitrage.

6. Cross-chain DeFi Protocol

While Lisks have several advantages in terms of throughput, they can also lead to fragmentation of liquidity, which can lead to increased slippage and reduced user experience. Cross-chain DeFi protocols can automatically split transactions between different chains for better pricing, which will lead to better user experience and a larger customer base.

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

The application chain implementation is divided into Cosmos, Polkadot and EVM L2. One possible way to improve composability is to build a general trustless cross-chain messaging protocol that can connect EVM L2, Cosmos zone, Polkadot parachains, etc. Such a product could replace existing cross-chain bridges and facilitate billions of dollars in transaction volume each year.

8. Enable cross-chain security sharing

Products that implement cross-chain security can be used to mitigate the security challenges of the application chain. Similar to merge-mining of PoW chains, we envision methods that allow security to be shared between unrelated PoS chains, e.g., validators staking ETH instead of native Lisk tokens to secure Lisk. Liquid staking protocols may play an important role in this.

Lisk Implementation

Lisk can be implemented in a number of ways, varying in complexity and security. This section briefly compares some options that help implement Lisk.

This article discusses the risks and opportunities of application chains such as Cosmos and Polkadot

1、Cosmsos Zone

Cosmos is the first ecosystem to envision multiple interconnected blockchain worlds. Based on this vision, Cosmos development is focused on standardizing and simplifying the process of launching private chains that can be interconnected. This work resulted in the Cosmos SDK, a modular framework for customizing and developing blockchains. The Cosmos SDK supports the Tendermint consensus mechanism by default, but also allows developers to use other consensus mechanisms. The Cosmos SDK was later improved by adding an IBC module that allows for trustless communication between Tendermint-based chains. Each of these chains is called a Zone, and to date, the Cosmos ecosystem has grown to over 45 Zones interconnected by more than 700 IBC Relays. Many of these Cosmos Zones serve single-purpose Lisks. One of the largest Cosmos Zones, Osmosis, is an application chain that implements AMM DEX.

Cosmos originally adopted the idea of ​​isolation security, that is, each Zone is responsible for its own security. This means that each zone needs to recruit a validator set to run the network and reward this validator set with the zone’s native token. While this approach is flexible, it increases the barrier to entry for Lisk builders. As such, Cosmos is implementing a change that will allow smaller Zones to recruit guards from the Cosmos hub via the Interchain Security (ICS) module.

2. Polkadot Parachain

Similar to Cosmos, Polkadot has also fostered a multi-chain ecosystem. 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 adopts a shared security scheme from the beginning, so all parachains share security with the Polkadot main chain (called the relay chain). The main function of the Polkadot relay chain is to provide consensus and security for parachains. Therefore, the relay chain cannot implement smart contract functions. Due to shared security guarantees, the Polkadot ecosystem does not allow the creation of parachains without permission. Instead, parachains need to have slots, which are auctioned off to developers who want to build custom chains. Bidders must lock DOTs to secure a parachain slot. As of now, there are 27 parachains that have won auction slots.

Different parachains on Polkadot can communicate via the Cross-Consensus Messaging (XCM) protocol. The implementation of XCM communication is in progress and is currently functional, but requires storing message data to the relay chain.

3. Avalanche subnet

Avalanche’s subnetting implementation is very similar to the Cosmos approach. Developers can start their own subnets, and each subnet can support multiple chains. Subnets need to recruit their own validators. However, in addition to validating the private subnet, these validators are also required to also validate the Avalanche mainnet. While this requirement increases the security of the main network, it increases the barrier to entry for private subnets compared to Cosmos.

Currently, the Avalanche subnet ecosystem does not support local inter-subnet communication, and subnets must develop their own cross-chain bridges. And the Avalanche team is working on adding this feature to increase the use of subnets.

4. Ethereum L2

In Ethereum, the term “Lisk” may not always accurately describe applications that require a dedicated environment. In Ethereum, such applications can be implemented either as a dedicated L2 or as a sidechain. The L2 implementation cannot be called Lisk as it does not implement the full chain stack. L2 is a rollup or validium that only performs transaction execution and ordering. For rollups, consensus and data availability are provided by Ethereum L1. For validium, L1 only provides consensus, and data is stored off-chain. Examples using this architecture include Sorare and Immutable X.

The other approach, sidechains, requires launching an independent blockchain verified by a small number of validators to achieve high throughput. Sidechains are typically connected to Ethereum via cross-chain bridges that are validated by a set of validators. The most well-known example of an application chain known to use a sidechain solution 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. L2 inherits security from Ethereum L1 via zk proofs or fraud proofs. Still, they can achieve very high throughput with negligible fees. These requirements are well suited to the needs of gaming applications. The main disadvantage of the L2 approach is that composability between L2s or between L2 and L1 is more difficult. Quickly transferring assets between rollups often requires a third-party provider, such as LayerZero. While there are techniques for trustless transfer of assets between rollups without going through L1, these techniques require significant delays that applications such as DeFi cannot tolerate. This is why DeFi protocols use generic L2s like Optimism and Arbitrum as scaling mechanisms instead of application-specific L2s.

Another challenge with using the L2 approach is the complexity of the implementation, there is no standard framework for launching an application-specific L2 on Ethereum compared to the relative simplicity of launching a Cosmos Lisk using the Cosmos SDk. However, this could change a bit in the future as Ethereum moves further on its rollup-centric roadmap.

in conclusion

The application chain theory is gaining traction, but it is heading in a different direction than originally envisioned. Lisk implementations on Cosmos, Polkadot, Avalanche, and Ethereum are converging into a shared security approach, with some nuances. With shared security, Lisk does not actually need a consensus mechanism. Instead, applications can just use a dedicated execution environment that serves the application and uses L1 for consensus and data availability. This execution environment can be a rollup or an independent execution layer following a modular blockchain approach.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-09-26 10:28
Next 2022-09-26 10:30

Related articles