Slow Burn
Why Not Appchains?
As we discussed last week, appchains have emerged as a compelling alternative to general-purpose L1 and L2 networks. In theory, they advertise an enhanced developer and user experience “without tradeoffs”; in practice, however, they are not completely able to deliver on their promise (yet).
A comprehensive evaluation of appchains requires understanding the associated technical and business-related complexities.
Technical: One of the greatest benefits of and challenges to building an appchain is flexible customization. Developers have unbridled control over their chain's performance, security, and governance characteristics. When executed properly, a bespoke chain that uniquely serves an application offers a superlative user experience. But creating this substrate is a multidisciplinary endeavor that can confound even skilled technical teams.
For example, in simpler implementations, appchains delegate security features to the main chain (“shared security”). This reduced technical lift still leaves developers with a number of concerns, including planning future upgrades (who can execute them—especially from a regulator's perspective) and determining transaction costs. Developers negotiate maintaining a low-cost environment that both is protected from bot/spam attacks and provides an engaging user experience.
Considering these technical challenges, many teams (particularly long-tail dApp developers) may find appchains an overwhelming option compared to established, general-purpose chains.
Business: General-purpose chains provide a secure and stable foundation, and immediate composability with other applications on the chain (which allows easier user acquisition). But in addition to constrained customization, L1/L2-based products have "backends" that are relatively trivial to fork. Consequently, only the only layer you "own"—the frontend and your brand—is defensible.
Conversely, appchains offer a vertically integrated approach where developers “own” the entire stack. Although an appealing concept, this also presents an isolation risk: appchains, as currently constructed, are inherently separate from a broader set of complementary protocols and dApps. User acquisition and liquidity generation are dependent on the team’s execution ability. Best case, you have a standalone and defensible on-chain application; worst case, you're Tom Hanks and Wilson. Some teams have managed to mitigate this risk. dYdX, for example, began on a general-purpose chain, cultivated an engaged user base, and then moved to an appchain.
The appchain landscape will continue to evolve, especially if teams can solve key issues such as interoperability (e.g., by offering appchain- or rollup-as-a-service platforms). However, building an appchain is far from a risk-free endeavor. History often rhymes, and fragmented, low-usage appchains feel eerily similar to the 2018-2019 gaming-focused side chains.
About Slow Burn
Weekly explorations into emerging crypto trends and how to navigate 2023 from the Slow Crypto Team, Sam Lessin, Clay Robbins, and Caroline Cline.