Note: In this post, we’ll cover the benefits of standing up an app-specific rollup, the costs of migrating away from a shared execution layer, and solutions to mitigate the associated costs.
I refer to app-specific rollups by many names–such as app rollup, app domain, app-specific domain, dedicated domain. I also refer to the creators of app rollups by many names–application protocol teams, dapp teams, dapp protocol teams, core teams, etc.
We’re at the beginning of an era in crypto that will be characterised by the proliferation of blockchains. Over the past year, we’ve seen the emergence of rollup frameworks (OP Stack, Arbitrum Orbit, ZK Stack, Sovereign, Stackr, Polygon CDK, Rollkit, Dymension RDK) and their accompanying Rollups-as-a-Service solutions (Caldera, Conduit, AltLayer), making it easier and easier to create a new rollup.
These new rollups are no longer confined to offering general purpose, one-size-fits-all solutions–like the blockchains before them. Instead, they can be configured with a high degree of customisation, allowing for never-before-seen domains to be created.
These next-generation rollups–app-specific rollups–are meticulously crafted to cater to precise use cases or specific sets of applications. Creating an app-specific rollup holds significant advantages for dapp teams, allowing them to optimise their domains in previously unattainable ways.
Blockchain-level customisation:
App-specific rollups allow for the optimisation of all parts of the modular blockchain stack. On the data availability layer, dapp teams can choose to have data availability submitted elsewhere (e.g., Celestia, DAC, a central server) in order to lower transaction costs.
On the execution layer, novel mechanisms (e.g., Narwhal and Bullshark consensus, FuelVM parallel execution) can be used in order to increase transaction throughput, increase block sizes, etc. Having a modular execution base allows teams to have a high degree of experimentation to determine what works for them.
In fact, using the Block SDK with ABCI++, dapp teams can even customise how blocks are built–creating priority lanes for certain types of transactions (e.g., bridging and oracle updates going top-of-block).
On the VM level, gas metering can also be customised. Teams can alter and optimise gas prices for common opcodes (e.g., pricing for storage vs. compute) based on their application’s usage. Different or multiple gas tokens can be selected, and certain transactions can be made gas-free or have gas sponsored by dapp team, effectively abstracting gas costs for users.
In an effort to have even more customisation controls, projects like dydx have opted to create their own application-specific chain (instead of rollup). In their case, dydx built a new base consensus mechanism from scratch that was tailor-made for their throughput needs and application logic requirements. Similarly, Sei and Monad have also opted to create their own L1 chains, making modifications at the base layer to cater to high-frequency trading and other traditional finance use cases.
Improved user experience
This heightened level of customisation also gives dapp teams more tools at their disposal to offer a greater experience to their users. Of course, blockchain-level customisations are ultimately in service of user experience–with higher throughput leading to less latency for user transaction inclusion and off-chain data availability leading to cheaper fees.
We also already touched upon gas metering controls that gives users cheaper transactions–and in some cases even offers free transactions.
In addition, by having a dedicated domain for one application, the dapp is not competing with other applications for blockspace (called the noisy neighbour problem) and thus prevents on-chain congestion and its associated high gas fees.
Moreover, permissioning controls within a domain are a powerful tool for elevating the user experience. App-specific domains can implement Know Your Customer (KYC) access controls, providing a level of identity verification and compliance, making them attractive to institutional capital.
To ensure users are exposed to high-quality applications, app-specific domains can incorporate permissioned deployment–like Osmosis and Kujira (Grown Up DeFi).. This allows dapp teams to curate the selection of app deployments.
Economics
It’s no secret that the rollups can make a lot of money–with L2s making over $6M in net profit (transaction fees minus L1 data and verification cost) in August alone.
By having a dedicated app-specific domain, dapp teams can capture gas fees generated by their application’s transactions. At scale, this revenue can be a significant.
In addition to gas fees, app-specific domains allow dapps to capture MEV within the protocol. This entails profiting from the value that the sequencer (or multiple) can extract from transaction ordering.
Transitioning to a dedicated domain, while advantageous in many ways, is not without its costs and drawbacks. One notable cost is the challenge of migrating existing and attracting new users to the new domain. Convincing users to bridge into an entirely new ecosystem can be a daunting task, which may lead to sizable user attrition.
Another notable cost is the loss of composability within the broader ecosystem. When moving away from a shared state layer, applications lose the ability to seamlessly interact with other projects and protocols on the same chain.
Let’s dive into how to overcome these two challenges in order to seamlessly migrate users and ensure connectivity to other applications.
(Re)acquiring users
One of the most significant challenges is (re)acquiring users. When a dapp decides to migrate to or launch on its own dedicated domain, it’s effectively rebuilding its user community from scratch. That’s because, on the new domain, the dapp faces the task of regaining users that were initially using the old version of the dapp on the old chain.
Dapps can significantly benefit from already possessing a sticky user base–one that will continue using the application regardless of the underlying chain it operates on. Engaging with this user base–often through incentives–-can make an easy, near-seamless transition from old chain to app-specific domain. However, even with these efforts, some users may choose to stay on the old chain or explore other options–leading to user attrition.
If the application protocol targets crypto users, one of their primary concerns is how to transfer their assets onto a new domain.
Usually, crypto veterans will simply bridge into the new domain from another chain. However, this requires a bit of trust on the new domain and the bridge infrastructure, as users need to have confidence in the security and reliability of the new domain.
Users sadly can’t transfer from a CEX directly because there’s no CEX integration into this new domain (and probably will never be–given the pace in which CEXs integrate new chains for withdrawal). Instead, users have to transfer from a CEX to a supported chain (e.g., Ethereum) and bridge from there–which is a painful UX.
Another effective strategy for bringing users onto the new domain is to abstract the bridging process, where users are “depositing” into an application-generated wallet. A notable example of this is FriendTech for Base, where users deposit their ETH on Ethereum L1 which then gets bridged into a new wallet generated by Privy. Similarly, Synthetix plans to implement a similar approach through Infinex.
Either way, both strategies require bridging–whether users manually doing it themselves or the application abstracting the actions underneath the hood.
Unfortunately, establishing bridge connections is a non-trivial ordeal. Existing bridge providers like Wormhole need to be convinced to deploy on the new chain–which, in practice, looks like going through a governance proposal process. For L2s, developing a token bridge to Ethereum is additional overhead that some rollups decided not to pursue (e.g., Linea at launch)
To overcome this, dapp teams can leverage Catalyst to connect to any desired chain right at launch. Catalyst is permissionless, so dapp teams can use it to connect to any Catalyst-deployed chain and move value between those chains and the new application-specific domain. This eliminates unnecessary BD and engineering work that would’ve been required to stand up bridges.
Ultimately, the gold standard is eliminating the need to bridge altogether. This can be achieved through the use of “intents”: performing actions on a home chain that subsequently propagate to the app-specific domain through solvers. By enabling seamless communication between chains, users can interact with the application from any home chain–bypassing the friction of bridging and making the transition to a dedicated domain less burdensome.
If the application protocol is targeting non-crypto users, the migration process is much simpler. Non-crypto users can continue using the same app with crypto running in the backend. There may be some NUX onboarding to teach users about the brand-new crypto features and–of course–a tutorial on how to get money into the application.
The easiest way to get money on-chain for new crypto users is to use an MPC wallet like Capsule (or something less powerful but more proven like Magic). This allows applications to support Web2 auth like creating a wallet with a Gmail account.
Afterwards, they can on-ramp directly on-chain from a bank account or credit card.
With all that said, even with a smooth asset transfer process into the domain, applications still need to convince their users that it’s worthwhile to keep their assets there.
The intuitive reason to keep assets on the app domain is the frequency of app usage. A dydx power user will obviously keep their assets on dydx chain–instead of going through the hassle of bridging in and out. In contrast, someone who uses dydx less frequently may be less interested in keeping their assets on dydx chain.
There is a measurable opportunity cost to keeping assets on one domain vs. another. The astute user knows that capital should be productive instead of idle, and there’s always more opportunities to chase in the world of crypto.
To combat this, application-specific domains can design a yield generation mechanism in order to incentivise users to keep their assets on their domain. This can come in the form of staking, yield farming opportunities, retroactive airdrops, etc.
“Incentives” don’t always have to imply native token emissions either. Application-specific domains create sustainable value generation engines that can be democratised and shared with their user bases. For example, a DEX domain can share protocol revenues, a compute/storage domain can share usage fees, a Web3 social domain can share content sales (i.e. collects).
Ecosystem accessibility
Many opponents of application-specific domains often cite the lack of composability that comes with a proliferation of app-specific domains. Applications operating on shared chains benefit from immediate, atomic access to the liquidity and assets already present on that chain.
Why does this matter?
Composability enables applications to tap into the liquidity of other protocols, allowing for better price execution (for swaps), competitive interest rates (for lending), and more resiliency in the system in case of a market downturn.
Shared state layers–that offer a high degree of composability–are able to facilitate atomic interactions between different DeFi protocols, enabling them to expand their range of services. Composability is how NFT projects are able to leverage Seaport and be listed on Opensea, or how an Liquid Staking Token gains more utility by being used as collateral on lending protocols.
Composability also allows applications to leverage smart contract logic from other protocols, lowering overhead to create new innovative products. For example, Alchemix deposits user assets into Aave and other yield-earning protocols in order to offer self-repaying loans, and Panoptic uses Uniswap V3 positions to make oracle-free options available.
By having composability, applications are able to offer more to their users: more utility, more services, and more ways to make user capital productive. More yield begets more capital and users, and it becomes a virtuous cycle.
More capital means more legitimacy. Convincing users to bridge into an entirely new ecosystem can be a hard sell, whereas transitioning to a chain with an existing ecosystem offers users more peace-of-mind.
Thus, losing composability and the access to other applications becomes the killer drawback of migrating to a dedicated app-specific domain. Mitigating this drawback of dedicated domains vs. shared chains is an ongoing challenge.
“The more high quality applications are on an atomic composability platform, the more sense it makes for new applications to join” — Informal Team
What if we could access the state of applications on another chain instantly and atomically? This would allow app-specific domains to have composability with protocols on more popular chains like Ethereum.
Solutions like storage proofs, used by Lagrange, Axiom, and Herodotus, do just that–allowing applications in dedicated domains to access the state and liquidity of other applications on different chains.
By leveraging SNARKs, storage proofs can verifiably prove that a specified state existed and was valid at a specified block height. Thus, storage proofs can be sent across domains and be used to execute cross-chain logic.
Using storage proofs, SphinxDEX validates the existence of liquidity across different blockchains such as Ethereum and Polygon (e.g., 10M USDC on Ethereum, 5M USDC on Polygon), and aggregates the liquidity into a single order book interface. The trading logic (i.e., execution) happens on a cheaper compute environment (i.e., StarkNet) while the settlement happens on the underlying chains.
Beyond storage proofs, shared ZK prover layers (e.g., Polygon 2.0 and ZK Stack by zkSync) are making L2s/L3s in their respective ecosystems feel like a single chain, boasting near-instant and atomic cross-rollup transactions.
This is possible by using a large recursive validity proof of the state transitions of every participating rollup–that is then settled into a common state layer like Ethereum L1. Since every rollup receives the same recursive proof, it can validate the state transitions of any inbound cross-chain message that the rollup receives.
Again, this only works if the rollups are using the same ZK prover scheme–which limits this to within one ecosystem.
Atomic IBC and shared sequencers (Astria and Espresso) have similar endgoals as shared ZK prover layers–with a very different implementation. They are creating shared blockspace across participating domains in order to guarantee atomic inclusion. However, atomic execution (i.e., validity checking transactions) remains an open area of research.
Engineering Overhead
It’s important to note that migrating users and access applications on other chains will become easier and easier as these technologies mature.
However, creating a dedicated domain will always demand more engineering effort and overhead compared to deploying on an established general-purpose blockchain (though the development effort will gradually become easier as well).
Moreover, creating a dedicated domain also requires a different engineering skill set vs. building and deploying smart contracts. For example, building a rollup using Rollkit will entail working with Go modules while developing smart contracts for EVM chains involves writing in Solidity/Vyper.
Existing infrastructure components like RPC endpoints, block explorers, and wallets may not be readily compatible with the new domain, requiring additional development and maintenance. Running this infrastructure independently can be financially burdensome, and convincing other organisations to run this infrastructure is a BD battle.
For applications already established on a general-purpose chain, migrating to a new domain involves extensive migration of state, liquidity, and users.
To recap, there are as many advantages to creating a dedicated application-specific domain as there are drawbacks. Variant said it best that it will be a tradeoff between connectivity and control.
The more independent and standalone an application is, the less drawbacks it will face when deploying its own dedicated domain.
Here are the compelling use cases where it makes sense to establish dedicated domains, each driven by specific requirements and objectives.
Gaming
Gaming applications often demand distinct parameters compared to financial applications, including lower security requirements, higher throughput, and ample storage capacity. Gaming economies are generally self-contained and thrive on controlling user engagement while avoiding congestion for an optimal user experience. On-chain games, in particular, benefit from a high degree of control, and the ability to implement custom features like gasless transactions can greatly enhance the gaming experience.
Standalone DeFi
Certain DeFi applications that do not rely on composability with a shared execution layer can effectively operate in their own dedicated domains. Use cases like payments (e.g., Chai from Terra 🥲) and derivatives (e.g., dydx, perps, structured products) come to mind.
For instance, projects such as Maker are considering transitioning to their dedicated chains to achieve greater control and customisation.
Social/Creator Economy
Projects within the web3 social, token gating, and community token sectors are actively exploring the development of their application-specific domains. These applications are self-contained and do not necessarily depend on cross-chain composability. This approach allows them to tailor their infrastructure to their specific needs and incorporate custom features, such as gasless transactions.
DePIN (Decentralised Physical Infrastructure Networks)
DePIN projects are an emerging use case that combine crypto with real-world infrastructure. Taking a page out of the A16z token playbook, these projects utilise tokens to incentivise the deployment of physical infrastructure in order to bootstrap initial network effects.
DePINs offer a more efficient and cost-effective approach to infrastructure deployment by removing intermediaries and democratising the collective ownership of a network.
These networks built on the ideas of 2017 blockchains that came before it (e.g., Helium, Omni Rentals, Grid+, HiveMapper), and they represent the next evolution of the Internet of Things (IoT) combined with Web3 technology–allowing device owners to own and monetise their own infrastructure.
Currently projects include Wynd Network, DIMO, IoTeX, and HealthBlocks, and projects like STEPN can leverage this playbook as well.
Infrastructure
A bit of a catch-all bucket, but various projects in the infrastructure sector are exploring the creation of their dedicated domains. Lit Protocol, for example, created a dedicated domain focused on access controls–while Entropy offers custodian-as-a-service solutions.
Synapse, Axelar, Wormhole Gateway, and Polymer are all specialised domains dedicated to enabling interoperability between different chains, rollups, and ecosystems.
Each of these use cases benefits from the flexibility and control provided by dedicated domains, allowing them to optimise their infrastructure, enhance user experiences, and cater to their specific needs and objectives.
Should you make an app-specific domain?
In summary, the decision to create a dedicated domain for your application hinges on a thorough evaluation of whether the advantages outweigh the associated costs.
When it comes to standalone applications like gaming, social/creator economy, and DePIN networks, the benefits of gaining full control over your domain often justify the upfront development investment and drawbacks. These applications don’t need to interact with other applications, and may even have non-crypto users (like DePIN) who don’t care about crypto ecosystem connectivity.
However, if your application absolutely needs to interact with an application for foundational logic (e.g., derivatives on an AMM, lending market of LSTs), then it’s not advisable to leave to a dedicated domain.
Everything in between those two ends of the spectrum will require thoughtful deliberation on tradeoffs.
If you have loyal existing users who will bridge to the new domain and bring meaningful volume, then the superior UX and economics will outweigh the development overhead and loss of ecosystem connectivity. If your users would prefer to stay in the existing ecosystem, remaining in the shared environment might be the best choice.
If you’re a brand new application that needs crypto users, then being part of an existing ecosystem with a built-in network effect of users and apps can be a significant advantage, potentially outweighing the benefits of having a dedicated domain.
In conclusion, the decision should align with your application’s specific objectives, existing user base, and requirements. A meticulous analysis of the trade-offs is imperative, allowing you to ascertain whether the benefits of establishing your dedicated domain align with your long-term goals and your users’ needs.
Resources
Trade-off Framework by Variant
Hitchhiker’s Guide to Rollups-as-a-Service
