Over 100 subscribers
The design space for blockchains has recently opened up: we no longer just have “monolithic” chains, but also:
data availability & consensus layers
rollups & execution environments
application-specific chains and more.
With many options to choose from, the most important question becomes not which design is best for decentralized platforms but which design gives decentralized platforms the best chance at competing with their centralized counterparts?
Since blockchain use cases differ, it is impossible to find a one-size-fits-all answer. This article will focus on appchains as one of the most viable and underexplored approaches to this challenge. It will dive into how appchains facilitate the creation of truly novel products and features, as well as explore the benefits of the sovereignty they provide. Though appchains are surfacing in various crypto verticals like DeFi and gaming, here we'll focus on DeFi appchains.
When we consider the various architectures mentioned above, it’s not immediately obvious which options are best for addressing important UX pain points while also remaining sufficiently decentralized. Every approach has trade-offs, but appchains offer one crucially important and unique advantage: Sovereignty.
From a technical perspective, sovereignty can be thought of as vertical integration. This means that application developers can control and customize every layer of the blockchain stack to meet the specific needs of their application, and do so in a way that allows for optimal integration between each layer.
Outside of the fact that technical sovereignty can mean less reliance on middleware solutions, it can also exempt applications from having to compete for blockspace with unrelated or competitor applications, as well as reduce reliance on the development roadmaps and governance of any other projects. These benefits will be especially compelling to projects that have achieved some notion of scale, need more throughput, require frequent upgrades, and/or desire predictability around how the platform they’re building upon will change and evolve.
Technical sovereignty also allows application developers to unleash their creativity through experimenting with different consensus models, bespoke node requirements, state models, and other exciting features which will be explored through the examples in the next sections. Just as many new L1s have emerged specifically to make changes to the core architecture that they lack the social consensus to implement on existing chains, appchains bring that same level of optimization to individual applications.
On the social side, sovereignty is fundamentally about individual applications having the ability to put their values first and get extremely specific about the set of trade-offs that make the most sense for them. It allows communities to be in control of their own fate and even take actions such as hard forking their blockchain, whether for political or technical reasons. Most projects that are willing to undertake the technical feat of building an appchain will do so primarily for technical reasons, but the demand for social sovereignty should not be underestimated. There are and will continue to be applications that opt into this vision simply because they do not feel that other ecosystems adequately share their values.
Appchains are not a perfect solution for all projects and ultimately represent an opinionated view on what trade-offs blockchains and applications should make. Many critics cite (1) the loss of synchronous composability and (2) liquidity fragmentation as reasons why the appchain approach is not well-suited to DeFi, however these concerns are not so straightforward. Just as liquidity on general-purpose L1s has become concentrated within a few popular applications, the same is likely to happen within the ecosystem of DeFi appchains. Rather than users toggling between DEX chains, lending chains, perps chains, liquid staking chains and the like, it’s much more likely that all these features eventually become consolidated into the core products of a few extremely liquid DeFi appchains, making fragmentation much less of an issue. It is also worth noting that while Ethereum Mainnet is still DeFi’s center of gravity, its rollup-centric scaling roadmap has its own implications for synchronous composability and liquidity fragmentation.
While appchains are by no means exclusive to the Cosmos ecosystem, many of them have chosen it as their home because of the robustness of the developer tooling and the asynchronous composability primitives, which do not yet exist for ecosystems like Ethereum.
When it comes to the current state of UX for most DeFi projects, here are just some of the pain points:
This list is not exhaustive, but it does begin to paint a picture of how many things DeFi applications need to get right in order to have a real chance of competing with CeFi. The following section will highlight a number of DeFi appchains that are tackling some of these problems head-on.
The best way to fully grasp the power of appchains is to explore some of the most compelling and innovative user experiences being built today, most notably on Osmosis, Mars Protocol, Penumbra and dYdX.
Osmosis is an appchain DEX and emerging liquidity hub within the Cosmos ecosystem. The original inspiration for Osmosis was outlined in a blog post by co-founder Sunny Aggarwal called DAOifying Uniswap Automated Market Maker Pools, where the core idea was to bring the customizability and sovereignty of Cosmos to the world of AMMs. Today, the protocol lets users create liquidity pools with unique and changeable parameters, allowing for experimentation with different kinds of bonding curves, multi-weighted asset pools, and more. Hybrid liquidity models that experiment with both order book matching and concentrated liquidity pools are also on the way.
As a trailblazer in the world of DeFi appchains, Osmosis has already introduced a number of innovative features to the market, including superfluid staking, which offers an elegant solution to the incentive problem that arises from having to choose between staking yields and DeFi yields. Users can instead stake any LP share token containing $OSMO, which incentivizes contributing to chain security while also driving additional value back to the community. This feature is made possible by the fact that the Osmosis chain can recognize application level-assets and use them in PoS consensus, and there’s no reason it cannot be leveraged for other similar use cases as more functionality and asset-types come online.
When it comes to creating a CEX-like user experience, Osmosis is working towards offering margin trading and lending as part of their core product. The team is currently working with Mars Protocol on integrating lending directly into the Osmosis trading engine, which will enable staged liquidations, cross-margining of assets and using Osmosis LP shares as collateral for margin trading. Osmosis writer Steview Woofwoof concisely outlined the benefits of this design in a Medium post earlier this year:
“Staged liquidations ensure that unexpected volatility will not immediately and catastrophically liquidate a levered position. Efficient cross-margining means that because the DEX and lending engine are so tightly coupled, Osmosis (unlike a stateless DEX) can track all your supplied collateral from different assets and pools block-by-block so that it can essentially be used as one big pool of collateral against all your loans and margin positions.
An additional benefit to building the lending protocol into the DEX is that it removes the need for an oracle. Indeed, it is possible that Osmosis price feeds will themselves be oracle-ized for use by other platforms. It may, of course, still be useful to use an external oracle for backup or added security against certain types of attacks (price manipulation, dDOS, etc.).”
Osmosis is also exploring several creative approaches to dealing with MEV on its DEX that are significantly more easy to implement as an appchain, including:
Threshold Encryption *– Encrypting user transactions before broadcasting them to block producers & allowing for decryption and execution only once the block has been voted on and finalized.*
Fee Discrimination – Charging different fees for different kinds of transactions (i.e. making arbitrage txs more expensive).
Skip*** ***– Building Flashbots-like features into the base protocol (i.e. auction slots within blocks).
Internalizing MEV* – Building in-protocol arbitrageurs that run at the beginning of each block and give the revenue to $OSMO stakers.
Mars is a cross-chain credit protocol being developed by Delphi Labs as well as the pioneer of a novel DeFi primitive known as Contract-to-Contract (C2C) lending. Originally deployed on Terra, the Mars team has since taken a step back to re-evaluate their product strategy and decide which ecosystem to invest in going forward. After surveying the entire landscape of L1s and L2s, the Mars team ultimately landed on a unique Outpost & Hub model that allows them to enjoy the benefits of deploying to an existing L1 and the benefits of appchain sovereignty.
Outposts are instances of the Red Bank, a non-custodial & over-collateralized lending protocol, that are deployed to various different chains – allowing for atomic synchronous composability with other applications on the same L1. It’s also where liquidity for C2C lending comes from, as authorized smart contracts can borrow from the Red Bank without posting collateral. The current plan is to build the first outpost on Osmosis.
The Mars Hub is an appchain that serves 2 key functions:
Governing all the outposts (including voting for which contracts can be approved for C2C lending)
Collecting revenue from all outposts & distributing it to $MARS stakers and validators
So far, the cross-chain strategy of most DeFi protocols has been to redeploy on all the popular L1s or build an appchain that needs bridges to connect to other chains. This Hub & Outpost model attempts to achieve the best of both worlds by composing with existing highly-liquid DeFi ecosystems and streamlining governance & token value accrual – both of which should alleviate some of the fragmentation issues that the predominant approaches suffer from.
The team at Delphi Labs is vocal about their hyperfocus on building the best possible UX for DeFi, and once live, Mars will be one of the most ambitious attempts to compete with the UX of centralized exchanges to date. The development roadmap includes a number of other exciting novel features such as Rover credit accounts, which will enable users to trade across various DeFi products with leverage from a single account and liquidation threshold, while also replicating the “sub-account” experience so many enjoy on CEXs. You can read more about it here.
Penumbra is a cross-chain shielded asset pool and appchain DEX that leverages privacy to improve the user experience of onchain trading and market-making. The vision for the project emerged out of frustrations around the lack of adoption and interest in privacy-preserving tools such as Zcash, and a desire to build a product that would be better precisely because of its privacy. However, as the last few years have shown, it turns out that privacy is a much harder problem than many initially appreciated (especially when building a private DEX).
There have been many well-funded attempts at building methods for doing private computation on blockchains, however the team at Penumbra has not been satisfied with any of the existing approaches. They’ve instead decided to ask a more subtle but critically important question:
If useful blockchains revolve around public shared state, how can we build a private ledger with useful functionality?
For Penumbra, the notion of public shared state is at the core of why blockchains are useful precisely because it means that anyone who wants to use a blockchain only needs to coordinate with the chain itself rather than with off-chain counterparties. Because of this, they take the view that while previous attempts at designing privacy-preserving L1s & rollups may solve the privacy issue, they do so in a way that severely limits the extent to which users can meaningfully interact with public shared state.
Ideally, private computation would be done in a way that preserves privacy for individuals while also allowing for transparency of important aggregate data. However, it turns out that building a system capable of managing these trade-offs requires a fundamentally different state model from anything in the market today, so the Penumbra team has been building one from scratch. Additionally, while they are currently very intentionally focused only on the use cases of trading and market-making, the research and design work being done by the team may have broader implications for privacy and scalability in other contexts.
Privacy on blockchains is accomplished by moving user data and execution off-chain: replacing onchain user data with cryptographic commitments to that data, and replacing cleartext execution with zero-knowledge proofs of correctness of state transitions. This requires a different state model. Rather than a state model centered on global, mutable state which valid transactions change as they execute, there is instead the notion of immutable, composable state fragments, where each transaction consumes input state fragments and produces output state fragments (this is conceptually similar to Bitcoin’s UTXO model). This allows state fragments to be replaced with commitments to those state fragments, while transaction contents can be replaced with proofs of valid state transition. The problem with this approach, however, is that because the execution moves off-chain, access to shared state is no longer possible, as the exact final output of the proposed state transition must be included as an input to the transaction. For instance, a DEX trade would require freezing the exact state of the AMM reserves and the exact output price, before submitting the transaction to the chain.
Penumbra’s state model is built first and foremost to facilitate private interaction with public shared state, which it does by using an actor model that explicitly separates off-chain computation, which is private and deals with per-user state, from on-chain computation, which is public and deals with shared state.
In the actor model, a user creates a message (rather than a transaction), encrypts it and sends it to a smart contract. Each smart contract is then executed once per block and takes as inputs all the messages sent to it during that block, allowing transactions to be processed in batches or using any other kind of custom application logic. This also has some nice scalability benefits in that the computational cost can be amortized over all transactions in the block since each contract is only being executed once. The validators will then decrypt some information about the batch total before executing the transactions asynchronously and producing public outputs.
This asynchronicity is made possible by the minting of a private NFT that records the intermediate state of the execution and models the future state. Once the contract responds with an output message, the private NFT is consumed and used to prove that the correct future state was being modeled, at which point the message from the contract is used to mint the private outputs of the execution. The trade-off here is that execution may take place over multiple blocks.
In order to preserve privacy for delegators and accountability for validators, the Penumbra team had to take a novel approach to how they designed staking. Instead of treating “unbonded” and “bonded” as different states of the same staking token, bonded stakes are recorded as delegation tokens. These tokens represent percentage shares of a validator’s delegation pool, much like how LP tokens represent shares within a liquidity pool. While the size of each validator’s delegation pool is part of the public chain state, delegation tokens retain privacy by being fungible with each other and residing in the multi-asset shielded pool (where all value on Penumbra is recorded). Lastly, staking rewards are calculated by tracking the exchange rate between staking tokens and delegation tokens, which has nice tax-efficiency benefits, as only unbonding is a taxable event.
Ultimately, the bet Penumbra is making is that privacy is actually integral to the experience of trading, and even more, that the customizations they’ve made will lead to better execution because enabling private strategies means enabling more sophisticated and well-capitalized players to enter the arena, which comes with better liquidity, better pricing and less slippage. The vision is to create a user experience that offers more privacy than CeFi with the open and permissionless benefits of DeFi.
After becoming the largest application by volume to be deployed to an Ethereum L2, perpetuals exchange dYdX recently announced their plans to build V4 as an appchain. In the official communications following the announcement, a “unique combination of decentralization, scalability and customizability” was cited as the primary reason for the move, however it’s worth digging a bit deeper into each of these reasons:
In the face of regulatory headwinds, especially in the US, many DeFi projects have been forced to confront the possibility of severe crackdowns, as well as how resilient their projects would be in the face of such actions. dYdX V3 is currently deployed to an Ethereum L2 (StarkEx), and while the details won’t be covered here, much has been written about the challenges around full decentralization for rollups. Despite the fact that solutions are actively being researched and developed, projects that need nearer-term solutions and predictability may not be able to wait for this vision of fully decentralized rollups to materialize. dYdX was one such project, and they ultimately decided that operating their own chain with ~100 validators would be the best they could do given the specific trade-offs they needed to make.
Given that dYdX V3 currently processes about 10 trades per second and about 1,000 order places/cancellations per second, the team surveyed the entire blockchain landscape in search of a chain that would allow them to scale that throughput up by orders of magnitude. Because they were able to find no such chain, they resorted to a more creative solution: a decentralized & off-chain order matching network. The realization that the dYdX chain only needs to reach consensus on which transactions have been settled, rather than on all orders being placed, will be the unlock for enabling truly superior scalability on V4.
At a technical level, this design was enabled by the fact that appchains allow for bespoke node requirements, such as requiring that validators help out with things like running oracle networks or bridging infrastructure.
In an interview with Bankless, dYdX founder Antonio Juliano shared his grand vision for a fully vertically integrated product and user experience that involves not only building the base L1, but also building custom execution modules, an off-chain orderbook network, an oracle network, an alchemy-like indexer, mobile applications and a custom wallet. Juliano himself has described this endeavor as “very risky,” but has also made it very clear that he believes this is the best available option for creating the highest quality possible user experience for the dYdX product.
For all the benefits and innovative experiments highlighted above, it is important to acknowledge that building an application-specific blockchain is significantly more technically challenging than deploying an application as a smart contract or even within a specialized execution environment (rollups, subnets, etc.) This reality should not be understated, however neither should the potential benefits that come from the vastly more open design space that appchains provide. Superior UX is not only how decentralized products beat out their centralized competitors, but it's also an integral part of building moat in an open-source, permissionless world.
Special thanks to the Sunny Aggarwal (Osmosis), Rob Sarrow (Delphi), Henry de Valence (Penumbra), and Aaron Kong for their extremely thoughtful notes and feedback! If you're building a DeFi-focused appchain or would like to discuss these topics further, feel free to reach out at natalie@volt.capital.
natalie
