While the first uses of blockchains were focused on money and banking, in recent years there has been a profusion of applications in areas such as art, games, and music, among others. In parallel, the aggregate number of users across these apps has grown superlinearly, putting strain on the underpinning infrastructure and deteriorating end-user UX. Furthermore, as they expand to meet demand, these apps require more customization options and more strong business structures. Application-specific blockchains, or "AppChains," are a new design paradigm that overcomes these challenges. Simply explained, an AppChain is a blockchain that devotes its block space to a certain application. Applications that construct AppChains can configure several levels of their stack, including their security model, charge token, and write rights, among others.AppChains are not a novel idea. Arweave for long-term storage and Bitcoin are two examples of application-specific blockchains. However, AppChain designs also include modular execution layers (such as rollups, sidechains, and plasma) that execute state transitions for applications but depend on a different settlement or consensus layer for finality. Monolithic blockchains, such as Osmosis, are just one example of such a modular execution layer.<h2>The history of AppChains</h2>It took a long time for blockchains to provide AppChain infrastructure to developers. While Cosmos and Polkadot accepted and expanded this notion in 2016, they did not completely launch their networks until early 2021. (with IBC and parachain functionality, respectively). Meanwhile, on the scalability front, there was increased demand for Ethereum blockspace, and transaction fees got excruciatingly high by the end of 2020, leaving developers anxious for alternatives. Simultaneously, Ethereum scalability research was gradually incorporated in the form of optimistic and ZK roll-ups and sidechains (together known as "L2s"). Polygon, Skale, zkSync, StarkWare, Optimism, and Arbitrum were all released in 2020 and 2021.As part of their commercial development initiatives, several foundation layers ("L1s") also recognized the value of supporting the Ethereum Virtual Machine (EVM). In 2020 and 2021, Avalanche (C-Chain), NEAR (Aurora), Polkadot (Moonbeam), and Cosmos (Evmos) all introduced chains that were EVM-compatible.On the application-specific design front, separately and concurrently, Celestia unveiled in 2019 (originally as LazyLedger) a novel modular design that divides the execution, settlement, and data availability layers of a conventional monolithic blockchain and enables application-specific blockchains without requiring the other components of the stack to be rebuilt.<img src="https://cdn.builder.news/news/11ed4dee52cab18ca8e6023f659fee92.jpg" alt="Modular and monolithic blockchains" title="Modular and monolithic blockchains" width="600" height="499" class="lykafe0">Modular and monolithic blockchains. Source: dberenzonThere are several platforms today that offer AppChain infrastructure. Given enough developer demand, some of them—such as Optimism and zkSync—may start offering support for dedicated execution levels even if they presently only offer shared blockspace layers.Axie introduced their Ethereum sidechain, Ronin, in early 2021. 46% of the Apecoin community still opted for ApeChain in mid-2022. And dYdX announced that their V4 will be built on the AppChain in mid-2022. Additionally, launching and interacting with AppChains has historically been challenging.<h2>The strengths of Appchains</h2>There are three key reasons why developers are increasingly turning to AppChains rather than establishing smart contracts on open blockspace.<h3>Performance</h3><ul><li>Because dApps battle for blockspace on the same network, it is common for one prominent dApp to consume an excessive amount of resources, increasing transaction costs and congestion for users of other dApps (e.g. Polygon and Arbitrum).</li><li>AppChains enables projects to keep transaction costs and latency low and predictable, resulting in a superior UX for end users.</li></ul><h3>Customizability</h3><ul><li>Developers must keep improving their applications for consumers as dApp gains in popularity.</li><li>Larger applications will need to trade off key design factors, like ecosystem compatibility, throughput, finality, levels of security, permission, and composability.&nbsp; For instance, validators may need high-performance hardware.</li><li>AppChains give established corporations an opportunity to experiment with Web3 without immediately turning completely permissionless; for instance, businesses might demand KYC-verified validators, screen developers who want to build on their network and decide which chains they wish to bridge assets to.</li></ul><h3>Value capture</h3><ul><li>While universal scaling solutions reduced transaction costs while maintaining security and developer quality, they provided developers with limited revenue options.</li><li>On the other side, there is a strong financial rationale for AppChains since apps may fork established protocols and monetize them within their ecosystem.</li><li>Furthermore, their token benefits from extra token sinks from being utilized as the security framework (i.e. staking token or gas token), in addition to a market repricing of that token towards something similar to an L2 or L1 token.</li><li>Additionally, an application's ability to run its own sequencers or validators allows it to capture MEV, opening up possibilities for new crypto-native business models. For instance, dYdX validators, who are probably going to be market makers, could charge users little to no fees while giving them slightly worse execution prices, akin to Robinhood's payment-for-order-flow model.</li><li>Another illustration is how many popular games intentionally work to be as moddable as possible by including a ton of modifications, extensions, skins, etc. However, most modifications are created by casual players who find it difficult to make money; if the game were an AppChain, modders could extend the IP on top of a rollup and make money by using that blockspace.</li></ul><h2>The downsides of AppChain</h2>However, there are some drawbacks to these advantages as well:<h3>Limited atomicity and composability</h3>Within other ecosystems, AppChains increase the degree of separation between consumers and infrastructure. This affects atomicity (an "all-or-nothing" property where either all sub-actions inside a single transaction are completed or none of them are) but does not affect composability (i.e., you merely need sufficiently excellent bridges over the same VMs).As a result of all apps being on the same settlement layer, atomicity is a unique attribute, yet it is not essential for many applications.<h3>Walled gardens recreated</h3>If all AppChains had permissioned read/write access, the consequent market structure would restrict permissionless &amp; composable advancement for developers and the capability of users to transact freely and opt out of systems, essentially reenacting the problems that crypto aims to address.<h3>Liquidity dispersion</h3>With AppChains, it will be necessary to bridge liquidity or assets from other levels or chains to that application and vice versa. Although bridging infrastructure makes this feasible, it increases end users' friction.Reflexive security modelIf the application token is utilized as the security model, there is an edge situation where there will no longer be economic stability for the app if the price of the token decreases to 0.<h3>Resource wastage</h3>If the program does not demand enough utilization, AppChains may be a waste of resources (physical or financial). If there are validators specifically assigned to the AppChain, they might be able to use their resources more effectively elsewhere.<h3>Further developer lift</h3>The management of extra infrastructure, like sequencers or validators, will be more difficult because it is not as straightforward as installing a smart contract.<h2>AppChains market structure</h2>Because of the several disadvantages of developing in a more closed ecosystem, AppChains are ideal for applications that have:<ul><li>Gotten a sense of scale (number of users, quantity of protocol revenue, TVL) and product-market standing.</li><li>Dedicated blockspace provides significant product/performance advantages.</li><li>Fewer demands for security and consistency.</li></ul>It follows that the bulk of applications will still be started on L1 and L2 systems with shared blockspace. In addition, teams, particularly DeFi protocols, will continue to launch on L1s due to their security, liquidity, and atomicity properties, the latter of which is particularly significant because flash loans provide practically infinite capital efficiency with no balance sheet risk. This is because the L2 landscape is still quite fragmented. Additionally, non-DeFi apps will probably start out on generalist L2s before switching to app-specific L3s or app-specific L1s if they grow to be sufficiently large to have network impacts.&nbsp;<img src="https://cdn.builder.news/news/11ed4dee52cab79ba8e6023f659fee92.jpg" alt="Dapps’ options" title="Dapps’ options" width="600" height="257" class="lykafe1">Dapps’ options. Source: VoltcapitalIt also makes sense that as most apps launching AppChains lack the resources necessary to bootstrap a large validator set, they would often pick modular execution layers (especially roll-ups) over monolithic chains. Furthermore, it is doubtful that top-tier validators will decide to devote their time and energy to an AppChain whose token has a low and erratic market price.However, as the crypto business develops and becomes more widely used, more apps will still start their own AppChains, and the future AppChain market structure will come in a variety of forms:<ul><li>App-specific monolithic blockchains linked by a number of bridges</li><li>App-specific sidechains attach to a monolithic chain</li><li>App-specific rollups that are built on a monolithic chain</li><li>Independent app-specific rollups that do not use a settlement layer</li></ul><h2>The AppChain design space</h2>When picking which AppChain infrastructure to build upon, there are numerous architectural considerations to consider:Security Level: How difficult is it to modify the status of the chain?<ul><li>Shared: The state is protected by numerous heterogeneous validators, which are most likely run by distinct parties (e.g. Polkadot parachains, Skale)</li><li>Isolated: Security given by the application itself; most likely via application-owned validators or sequencers, and economic stake given by the application's token (e.g. Cosmos chains, Axie Ronin)</li></ul>Security Origin: Where does security originate, and where does settlement take place?<ul><li>Ethereum: Ethereum is used as the settlement layer for fraud and validity proofs, as well as general double spent prevention (e.g. Arbitrum, zkSync)</li><li>Non-Ethereum L1: Does not use Ethereum security and may use a different consensus process entirely (e.g. NEAR Aurora, Tezos rollups)</li><li>Application token: The token of an application is utilized for base security&nbsp; (Avalanche subnets, Cosmos chains).</li></ul>Permissioning: How nodes are chosen, and who has access to the state?<ul><li>Permissionless: Nobody needs permission to read/write contracts or validate state transitions (e.g. Optimism, StarkNet)</li><li>Permissioned-by-choice: The chain may only be read/written/validated by whitelisted validators/developers (e.g. Polygon Supernets, Avalanche Subnets)</li></ul>Composability: refers to how easy and secure it is for liquidity and state to transfer across apps within a given ecosystem.<ul><li>Full: Moves to any application with the least amount of latency and the greatest amount of security (e.g. Polkadot XCMP, Cosmos IBC)</li><li>Limited: Has connection, latency, and/or security limits (e.g. Avalanche Subnets, Polygon Supernets)</li></ul>Finality: When are transactions accomplished? (Assuming that final is deemed probabilistically final)<ul><li>Instant: Usually using BFT consensus methods (e.g. NEAR Aurora, Evmos)</li><li>Eventual: This is common with rollups, where a transaction is considered final after the block has been uploaded to L1 (provided data is available) (e.g. Arbitrum, zkSync)</li></ul>Gas currency: Which token is used to pay for transactions by users?<ul><li>Non-application token: The basic asset of the L1 or L2 upon which the application is constructed (e.g. Ethereum, Evmos)</li><li>Application token: Typically, the application token runs on an app-specific L1 or L2 processor (e.g. Avalanche Subnets, Osmosis)</li><li>None: Users' hardware expenditures are subsidized by L1 or L2 validators or applications. (e.g&nbsp; AltLayer, Skale)</li></ul>There are a few more obvious factors:<ul><li>The amount of stake necessary for apps to have validators in order to safeguard their chain.</li><li>Transactions-per-second (TPS): a subjective metric of throughput due to the variability of transaction sizes (i.e. larger transactions will cause lower TPS and vice versa)</li><li>Support for EVM opcodes: The capability to support both Solidity and EVM opcodes without requiring developers to rewrite their software.</li></ul>We may map existing AppChain solutions based on the following criteria:<img src="https://cdn.builder.news/news/11ed4dee52cabb91a8e6023f659fee92.jpg" alt="Appchains criteria mapping" title="Appchains criteria mapping" width="600" height="229" class="lykafe2">Appchains criteria mapping. Source: MediumConclusionDespite the current challenges with AppChains, developer demand indicates that they will continue to expand. Vertical integration, as proved by Apple, typically leads to superior UX; similarly, blockchain developers will want to provide fully-optimized web3 apps, which AppChains enable. However, AppChains are not for everyone, and developers should consider their application's demands as well as the inherent trade-offs before devoting resources to establishing one.The ramifications for security model economics, monetization tactics, platform defensibility, total value accrual throughout the stack, and second-order repercussions on the crypto market structure will be fascinating to watch over the next several years. While nobody is sure which section will reign supreme, there is one thing we can rest assured of: the blockchain industry is evolving every day. As there is more and more attention pouring into this industry, all the AppChains we have today are sure to be improved and ready for mass adoption.<div class="pr-block-special">Disclaimer: This article is intended for and only to be used for reference purposes only. No such information provided constitutes advice or a recommendation that any investment or trading strategy is suitable for any specific name.</div>

Applications that construct AppChains can configure several levels of their stack, including their security model, charge token, and write rights, among others.

AppChains 101: All about application-specific blockchain