Andre Cronje's latest article: Value capture should return to the application, rather than being taken by the network

Original Title: "To appchain or not to appchain"

Author: Andre Cronje

Translated by: Deep Tide TechFlow

It all started with a tweet:

Andre Cronje:

• Why L2 as an appchain is not very reasonable for developers:
• Almost no infrastructure support at deployment, such as stablecoins, oracles, and institutional custody.
• Lack of support from foundations or labs.
• Centralization, making it vulnerable to attacks.
• Leads to fragmented liquidity, requiring reliance on bridges.
• Lack of user and developer communities.
• Time spent dealing with these issues instead of focusing on applications and users.
• Weakens network effects.
• Still has long transaction confirmation times (some providers won't work with you).
• Developing in isolation, without team support.

This experience exposed me to many product recommendations, one of which particularly caught my attention (of course, there are many other cool products);

Surprisingly, they launched my own appchain in just a few minutes.

From a technical perspective, this excited me greatly because there were many new solutions I hadn't encountered before, and I have always been keen on learning new technologies, so I began to delve deeper.

The idea of having my own tech stack, including native stablecoins, oracles, proof systems, network effects, bridging, and interoperability, sounded too good to be true.

It seemed somewhat unrealistic (but not entirely so), so I started with what I considered the two biggest obstacles: native stablecoin issuance and trustworthy oracles. Going through this process with Sonic recently (and spending over $5 million) made me realize how humbling and somewhat embarrassing it would be if I could get all of this for free.

Among the recommendations, noble.xyz intrigued me the most because it claims to provide native USDC and CCTP for any IBC-enabled chain. First of all, it's a cool product, but it’s not native USDC or CCTP; it’s a bridge that issues assets through its blockchain and then transfers them to other integrated chains via IBC (the interoperability version of the Cosmos ecosystem, which is excellent). This is neither automatic nor free, and certainly not native or CCTP.

That said, we can also look at other solutions like LayerZero and AcrossProtocol, which are both great protocols. We have collaborated a lot with LayerZero, and they are outstanding; I highly recommend any chain to work with them, but this is still not native issuance. I know this sounds nitpicky, but after experiencing various issues with bridges, nothing beats native issuance in terms of trust and scale. If you want native issuance, you need to be prepared with funding.

On the oracle front, I received recommendations for skipprotocol, storkoracle, and redstone_defi, but unfortunately, these products are not plug-and-play and require integration, and I’m not sure if there would be additional costs. Here, I feel it’s necessary to discuss the scale issue. My assumption is that anyone wanting to become L1 or L2 would hope to break into the top 50, 20, or 10 (whether by trading volume, total locked value, or market cap). However, this does not always apply; some applications do not need to be that big. I experienced this with the Keep3r network, where everyone expected it to become another Yearn, but it was never intended to be that way. Yearn is akin to an asset management company, while Keep3r is a niche operational tool, and the two do not require the same evaluation criteria. Therefore, this article is not meant to belittle the value of these products; as I said, they are all excellent, but if you assume you need to launch an L2 or L1 appchain to compete with Arbitrum, Optimism, Solana, Avax, etc., these solutions seem insufficient.

Next, let's talk about development tools and wallets, which are compatible with any new chain, but users and developers need to manually configure those RPCs. While this is not a major issue, it does add some unnecessary friction.

Lastly, there’s the block explorer, and I must mention Blockscout, which is the benchmark for free explorers. There’s not much more to say; they are excellent. However, paid products like etherscan often have advantages because they have dedicated paid teams.

Of course, this does not solve the issues of interoperability or network effects. Take unichain as an example; if uniswap is the only application on that chain (though unlikely, let’s assume), how much trading volume would it have? How much volume is from arbitrage with other AMMs, how much is from liquidating positions in money markets, and how much is from other undesirable flash loan activities? Isolated, trading fees would decrease, and it is precisely composability and interoperability that provide assistance.

I read some content about clusters and superchains, and I admit that either I did not understand it thoroughly (which is likely) or it has no practical significance in practice.

Now, to say the last word, it actually doesn’t make much sense. The ability to launch your own L1 or L2 in a few minutes, equipped with explorers, RPCs, bridging, etc., is indeed astonishing. But is it really practical?

Taking Unichain as an example (sorry, I’ve been focusing on Unichain; I genuinely think they might be one of the few exceptions because they have huge network effects, but please bear with me on this example), one important reason they built this chain is to capture value. Look at the following tweet:

Uniswap alone on Ethereum generated $2.439 billion in Gas fees for validators. This does not include MEV extraction (as sorters, they can capture). This $2.5 billion could have been earned by Uniswap itself, but it flowed to the validators. That’s a massive number.

So, what if we could address this issue more practically, without running our own chain, explorer, RPC provider, guiding users and developers to configure RPC in wallets and development tools, and without integrating oracles and native stablecoins? What problem are we trying to solve? It’s actually about capturing value back to the applications instead of letting it be taken by the network. Isn’t there a simple solution to this? In our creator economy, hasn’t this problem basically been solved? The answer is revenue sharing. Platforms like YouTube, Twitch, X, etc., share revenue with creators. Therefore, a more practical solution would be to distribute these Gas fees to the applications, right?

I want to ask, what other practical reasons are there? Of course, the low latency issue has basically been resolved by modern blockchains (like Sonic, Avax assuming you need EVM, Solana SVM, Sui MoveVM). Our throughput is also high enough; most chains I just mentioned are more efficient than the current Layer 2s. So, if the issue is not speed, and not throughput, then it must be the value capture issue. Who can blame them? Sorter fees are a new revenue model (essentially keeping all network fees for themselves instead of sharing with decentralized value-extracting validators; just kidding, I actually like validators).

So, revenue sharing, right? This way, all the troubles are solved, and all the benefits are gained.

Appchains seem to be yet another engineering solution created to solve a problem. Don’t get me wrong; my inner tech enthusiast loves it, but as a practical developer, I can’t help but ask: what’s the point?