To appchain or not to appchain

It started with a tweet;

This led to quite a few product recommendations, one that especially caught my eye was (there were many other cool ones as well);

And very impressively, within a few minutes, they had launched my very own appchain;

From a technology perspective, this excited me, here were a lot of new solutions I had not previously had exposure to, and I always love learning about new tech, so down the rabbit hole I went.

The idea of being able to have your own stack, inclusive of; native stable coins, oracles, proof systems, network effects, bridges, and interoperability sounds to good to be true.

And it kind of is (but also isn’t), so I started with the two biggest hurdles I consider; native stable coin issuance, and trusted oracles. Having very recently gone through this exercise with launching Sonic (and after having spent > $5m) the idea of having this all for free humbled (and embarrassed) me. There were quite a few recommendations, noble.xyz was the most interesting given that it claims Native USDC and CCTP for any IBC enabled chain. Now, first off, this is a cool product, but its not native USDC or CCTP, it is a bridge for the assets issued on its blockchain and then via IBC (cosmos ecosystem version of interoperability [which is amazing btw]) transfers to other integrated chains. This is not automatic, this is not free, this is not native or CCTP. That being said, let’s look at the other alternatives provided such as LayerZero, AcrossProtocol, which again, fantastic protocols, we have worked a lot with LayerZero and they are wonderful and I would highly recommend any chain to work with them, but this is not native issuance. Now I know this is pedantic, but after everything that has happened with bridges, nothing really beats native issuance in terms of trust and scale, and if you want native issuance, you will need to open that wallet.

Oracles, I was recommended skipprotocol, storkoracle, redstone_defi, which sadly none of which are available out of the box and need integration, not sure if there are fee overheads, and here, I think it is important to have a note on scale, my assumption is that anyone going through the effort of being an L1 or L2, want to hit those top 50, 20, 10 numbers (be it volume, tvl, marketcap, whatever). That is not always true, some apps don’t need to be that big, I went through this with Keep3r network, everyone expected it to be another Yearn, it was never intended to be one, Yearn was equivalent to an asset management company, Keep3r was a niche devops tool, these things don’t need the same evaluation. So this entire article is not to discount the value of these products, as I said, all very cool, but if we assume you are launching an L2 or L1 appchain to compete with the likes of Arbitrum, Optimism, Solana, Avax, etc then these are not comprehensive.

Next, lets talk dev tools and wallets, these ARE compatible with any new chain, however, your users and devs need to manually configure those RPC’s, not that of a big deal, but also just another bit of unneeded friction.

Lastly explorers, gotta give it to Blockscout, they are the standard in free explorers. Nothing more to say here, they are awesome. But, a paid product like etherscan will tend to have the edge, because they have a paid dedicated team.

Now sure, this doesn’t address the issues of interoperability or network effects, using unichain as an example, if uniswap was the only thing on that chain (it won’t be, but just go with my hypothetical), how much trading volume would it really have? How much volume is arbitrage with other AMM’s, how much is liquidating positions in money markets, how much is other more nefarious flashloan activity. In isolation, it would be generating less fees, its the composability and interoperability that helps. Now, I read up on clusters and superchains, and I will admit, I am either not understanding it (which is very likely), or it doesn’t make sense practically.

Now that last line, doesn’t make sense practically, the idea of being able to launch your own L1 or L2 within a few minutes and have explorers, rpc’s, bridges, etc, let’s face it, that’s awesome. But is it practical?

Looking at Unichain (and sorry I am focusing on unichain, I do think they are probably one of the few exceptions since they have massive network effects, but just go with me on this one), a big reason for their chain is value capture, look at the below tweet (sorry x… not sure what the active form of x is);

Uniswap on Ethereum alone has generated $2,439,295,129.10 in gas fees for validators. That’s not mentioning MEV extraction (which as a sequencer they can capture). $2.5bn, that Uniswap could have earned, but instead went to validators. That is a massive number.

So what if we can solve this a bit more practically, without needing to run our own chain, explorer, rpc providers, guide users and devs on rpc configuration in wallets and devtools, integrate oracles and native stable coins. What are we trying to solve? We are trying to solve value capture back to the app instead of the network. Isn’t there a simple solution there? Hasn’t this already been pretty much solved in our creator economy world? Its revshare. Youtube, Twitch, X, whatever, they all give the creator a % of the revenue. So isn’t a more practical solution to simply give those gas fees to the app? I mean, whatever other real practical reason is there? Sure, low ttf, modern blockchains pretty much have that nailed (Sonic, Avax assuming you want EVM, Solana SVM, Sui MoveVM). We have high enough throughput, most of the chains I just mentioned are all more performant than current Layer 2’s. So if the issue isn’t speed, and it isn’t throughput, then surely it has to be value capture? And how can you blame them, sequencer fees are the new revenue model (essentially getting all network fees for yourself instead of needing to share it with pesky decentralized value extracting validators [kidding, I love validators]).

So, rev share, no? All the headaches gone, all the benefits gained.

Appchains again feel like an engineering solution looking for a problem, and don’t get me wrong, the technologist in me freaking loves it, but the practical builder in me is left wondering why.