A dApp developer’s guide to appchains.

This post originally was written for, and published in, Slow Venture's Snail Mail

This week's post features insights from Jake Nyquist, Co-Founder and CEO of Hook. Hook is the NFT-native options protocol and is in the Slow portfolio.

The Ethereum community has spent the last 3 months buzzing with a new narrative around app-specific rollups. They’re heralded as an easy way for projects to build custom chains with no congestion, fees 10-100x lower than Ethereum, and even a new source of revenue.

The growing hype means project founders need to decide if they’re going to invest in a rollup for their project. Unfortunately, despite the active debate, there's very limited information to help you decide if — and how — to launch your app-specific rollup.

TL;DR

If lower fees for users + higher throughput + more profits sounds too good to be true, you're right. In reality, app developers must shift from thinking of the gas as a fee paid by users to viewing the chain as its own PnL. Unlike the per-transaction fees on ETH or Optimism, an operating rollup has both fixed and variable costs. For most apps, operating a rollup is more expensive than just using an existing L2.

Worse, today’s default choice of rollup framework likely isn’t the best for most app developers because it combines the highest costs with the worst security guarantees.

What rollups actually cost

Your chain's per-transaction costs ultimately depend on your trust assumptions, target chain performance (i.e. block time), and the number of monthly transactions.

*note: adapted from Sanjay Shah's* *post* *on rollup value accrual*

However, this per-transaction view hides the complexity that rollups are a mix of upfront, fixed, and variable costs. Setting up a rollup costs just a few ETH in contract deploys. Once the chain is running, there are three main cost categories to consider.

Sequencer Hosting. The cheapest way to host a sequencer is deploying it on AWS, which might cost as little as $700/mo Realistically, most teams will skip this complexity and opt for a sequencer-as-a-service provider like Caldera (~$5k/mo, on AWS) or Conduit (~12.5k/mo, on GCP).
State root posting. State roots only require one word of storage to be saved to the parent chain, so should cost approximately $50/day.
Calldata posting. Rollups post a sequence of compressed calldata for each transaction to its Data Availability (DA) layer, normally ETH. The gas costs to post range from $200 - $20k daily to post depending on chain configuration and usage.
Proving (zk chains only). ZK rollups will need to run a computationally expensive prover to construct a proof that each published state is valid, and then pay gas to verify those proofs onchain.

When considering the full range of cost inputs, rollup economics look more like this:

From an economics perspective, low throughput chains utilizing OP Stack simply don’t work… the costs of posting a transaction every block will make the per transaction cost far higher than using an existing public L2. To illustrate, I modeled the fixed and variable cost of running various chains, based on an average transaction submitted 1k and 100k times daily, at multiple block times. A comparable transaction might cost $0.15 to execute on Optimism’s public L2. Very high transaction throughput, in the range of 50-100k daily transactions, is required to make rollups have equivalent per-transaction costs as a public L2.

Calculations rounded. Assume 25 gwei ETH gas price, 400k transaction gas usage. Alt DA doesn’t exist yet, assumes 1/10’s ETH DA. See additional assumptions and customize for your use case by copying this Google Sheet.

In the case of OP Stack rollups, there's a clear relationship between block time and the required daily transactions to achieve cost parity with Optimism. With 1-second block times, the rollup must process over 60k transactions every day to achieve parity—and that's with a low ETH gas price. However, by increasing the block time to 12 seconds, the same parity could be achieved with only ~10k transactions daily.

Architecturally, Arbitrum Orbit chains simply do not suffer from this issue. Blocks won’t be built if there are no pending user transactions, unlike in the OP Stack. This feature allows Arbitrum Orbit chains to be almost strictly cheaper to operate than Optimism chains, and they can have 250ms block times by default. As an added benefit, Arbitrum Orbit chains have much stronger trust assumptions than OP Stack chains. They have a readily available prover and the ability to allow fraud proofs to be permissionlessly submitted even before the BOLD proposal is approved for the Arbitrum One chain. OP Stack has neither of these core features.

What can projects do to cut these costs?

Utilizing an upcoming propose-built DA, like Celestia or EigenDA could also reduce costs by 10x – and introduces additional implementation complexity. Your chain is only as secure as that DA because, if the DA becomes unavailable or incorrect DA, no one can prove fraud. As an app developer, it’s important to consider how much this security matters: currently, there is no ability to create fraud proofs on OP Stack chains. This means that the posted calldata, available or not, can’t be used to improve the security of the chain. Users must trust members of a committee to prevent fraud. The DA costs–the largest single cost of the chain–are being wasted.

Orbit chains save slightly on DA by default because the calldata is posted to Arbitrum One, which charges less than posting the same transactions directly to ETH. Arbitrum eventually posts this data to ETH. Because Orbit chain’s inbox and outbox contracts sit on Arbitrum, the computation costs incurred on bridging between Arbitrum and the rollup are significantly lower than the rolling up directly to ETH. A L3 chain can also save users’ funds with cheaper CEX deposits and withdrawals.

The downside of using Arbitrum Orbit is that bridging from ETH to the rollup requires waiting for multiple hops on the native bride and Arbitrum’s 7-day dispute period. Developers can use third-party bridges like Hyperlane or LayerZero to allow for faster withdrawals, but these bridges have historically been prone to major hacks (see Wormhole etc).

ZK chains incur additional computation costs on the base chain to verify their proofs and have much higher sequencer requirements to generate these proofs. In exchange, the ZK chains will support much faster finality, and not require a dispute window.

How are projects rationalizing rollups?

The vast majority of incumbent dApps do not have enough transactions to justify deploying a chain instead of relying on an existing L2. Given that, what are some good reasons to build one?

Bootstrap real network effects (Zora, Base): Bringing other developers to your chain when they want to access your users is a way to convert from a product to a platform.

For example, Coinbase may give developers access to its large network of KYC’d users if they deploy on Base. The deployed dApps generate sequencer revenue and enhance the value proposition for Coinbase’s users. Other developers can deploy directly on these rollups because they’re EVM-compatible.

Developers interested in these network effects will likely opt for EVM-compatible, L2 rollups that use ETH for DA due to their security and bridging concerns. OP Stack deploys are already popular for this use case, and other developers may negotiate with the Arbitrum DAO to use their implementation.

Provide a superior UX & build a closed sandbox (Aevo, Games): Rollups can power better UX by shielding users from variable transaction costs and chain congestion. Rollups make it easy for developers to predictably sponsor all gas costs. dApp users benefit from a web2-like experience and blockchain security.

If you’re sponsoring gas for your users it may be better to operate a chain even if the economics work on an existing L2. Those L2s are highly profitable, and so at scale, your COGS will decrease by deploying a rollup instead of paying the third party.

Arbitrum Orbit chains may be the best solution for developers in this category because of their superior economics without depending on ultra-high transaction throughput.

Chain hacks and purpose-built chains (Future dApps): App-specific rollups also allow developers to customize the chain to suit their apps. This is possible because developers can modify the execution layer of their chain with custom code that powers a unique feature.

OP Stack will be less competitive for these use cases because customized chains can’t participate in their “Superchain”. Arbitrum Orbit chains will likely work for basic customization and EVM compatibility. Stylus might power more advanced use cases. Emerging providers like Sovereign and Eclipse allow developers to customize their chains more deeply and will compete here.

At the most extreme, developers could skip a rollup and just build an app-specific chain on Cosmos, like dYdX has for their v4. Doing this, the most customizability is possible but is, by far, the most expensive option.

What choices do you need to make

Given all of this, there are a few initial questions you need to answer to define your appchain strategy.

Do you even need a rollup?

If you don’t have sufficient transaction throughput, and none of the alternative motives are worthwhile for your project, you don’t need an appchain. This is the majority of projects.

How much do you care about security?

If you do need an appchain, compromising on security (by electing to use an alternative DA) is the biggest way to cut costs. In practice, using eth for DA is not critical for most use cases, so make sure you need that layer of security.

Which rollup framework do you launch on?

Does it matter that you’re “settling on Ethereum”? How many transactions do you expect to process each day? Do you need a great native bridge?

What is the regulatory risk associated with an appchain?

Appchains are generally less decentralized than deploying on ETH, and this could expose app developers to additional legal risks. Decentralized sequencers like Astria or Espresso could help, but there isn’t a clear legal framework indicating this makes a real difference.

Does the appchain make my UX worse?

Changing chains is very confusing for users, and most of their existing tools like Etherscan and ENS won’t work the same way on your chain. You’ll have to do additional work like mirroring ENS addresses or work with additional providers, like Dora for block explorers, to solve these UX challenges.