Author: Andre Cronje
Compiled by: TechFlow
It started with a tweet:
Why L2 as an application chain is not very reasonable for developers:
Almost no infrastructure support during deployment, such as stablecoins, oracles and institutional custody.
Lack of foundation or lab support.
Centralized, easy to attack.
Causes liquidity fragmentation, needs to rely on bridges.
Lack of user and developer community.
Time spent on solving these problems rather than focusing on applications and users.
Weakens network effects.
Still have relatively long transaction confirmation times (some providers won't work with you)
Developed alone, without a team support.
This experience has exposed me to many product recommendations, one of which particularly caught my attention (of course, there are many other very cool products);
Surprisingly, they launched my own application chain in just a few minutes.
From a technical perspective, this is very exciting to me, as there are many new solutions here that I haven't encountered before, and I've always been passionate about learning new technologies, so I started to delve into it.
The idea of having your own tech stack, including native stablecoins, oracles, proof systems, network effects, bridges and interoperability, sounds wonderful.
This sounds a bit unrealistic (but not entirely), so I started with what I think are the two biggest hurdles: native stablecoin issuance and trusted oracles. Going through this process when Sonic was recently launched (and spending over $5 million), made me realize that if I could get all of this for free, it would make me feel both humble and a bit embarrassed.
Among the recommendations, noble.xyz is the one that interests me the most, as it claims to provide native USDC and CCTP for any IBC-enabled chain. First of all, this is a really cool product, but it's not a native USDC or CCTP, but a bridge to issue assets on its blockchain and then transfer them to other integrated chains through IBC (the interoperability version of the Cosmos ecosystem, which is excellent). This is not automatic, not free, and not native or CCTP.
That said, we can also look at other solutions like LayerZero and AcrossProtocol, which are great protocols. We've collaborated a lot with LayerZero, and they're excellent, and I strongly recommend any chain to work with them, but this still isn't native issuance. I know this is a bit nitpicky, but after going through the various issues with bridges, there's nothing better than native issuance in terms of trust and scale. If you want native issuance, you need to be prepared to fund it.
In terms of oracles, I received recommendations for skipprotocol, storkoracle and redstone_defi, but unfortunately these products are not plug-and-play, they require integration, and I'm not sure if there will be additional fees. Here, I feel it's necessary to discuss the issue of scale. My assumption is that anyone who wants to become an L1 or L2 hopes to be in the top 50, 20 or 10 (whether in terms of trading volume, total locked value or market capitalization). However, this is not always the case, as some applications don't need to be that big. I've experienced this with the Keep3r Network, where everyone expected it to become another Yearn, but it never intended to be that. Yearn is similar to an asset management company, while Keep3r is a niche operations tool, and these two don't need the same evaluation criteria. So this article is not meant to undermine the value of these products, as I said, they are all excellent, but if you assume you're launching an L2 or L1 application chain to compete with Arbitrum, Optimism, Solana, Avax, etc., these solutions may not be comprehensive enough.
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 big deal, it does add some unnecessary friction.
Finally, there's the block explorer, and Blockscout has to be mentioned, as it's the benchmark for free explorers. There's not much more to say, they're excellent. However, paid products like Etherscan often have advantages because they have dedicated paid teams.
Of course, this doesn't solve the issues of interoperability or network effects. Take Unichain as an example, if Uniswap is the only application on that chain (although unlikely, but let's assume), how much trading volume would it have? How much of that volume is arbitrage between other AMMs, how much is liquidating positions in the money market, and how much is other undesirable flash loan activity? In isolation, the transaction fees would decrease, and it's the composability and interoperability that provide the help.
I've read some content about clusters and super-chains, and I admit, either I didn't understand it thoroughly (which is likely), or it doesn't have practical meaning in practice.
Now to the last sentence, it's actually not very reasonable. Being able to launch your own L1 or L2 in a few minutes, equipped with a browser, RPC, bridges, etc., is indeed impressive. But is it practical?
Take Unichain as an example (sorry, I've been focusing on Unichain, I do think they may be one of the few exceptions, as they have a huge network effect, but please bear with me on this example), one of the key reasons they built this chain is to capture value. Look at this tweet:
Uniswap on Ethereum alone generated $2.439 billion in Gas fees for validators. This doesn't even include the MEV extraction (as sequencers, they can capture it). This $2.5 billion could have been earned by Uniswap itself, but instead went to the validators. This is a very large number.
Here is the English translation:Well, what if we could solve this problem more practically, without running our own chain, browser, RPC provider, or guiding users and developers to configure RPC in wallets and development tools, and without integrating oracles and local stablecoins? What problem are we trying to solve? It's actually about capturing value back to the application, rather than having the network take it away. Doesn't this have a simple solution? In our creator economy, hasn't this problem been basically solved? The answer is revenue sharing. Platforms like YouTube, Twitch, and X all share revenue with creators. So, a more practical solution wouldn't it be to share those Gas fees with the applications?
I wonder, what other practical reasons are there? Of course, the low latency issue, which modern blockchains have basically solved (like Sonic, Avax if you need EVM, Solana SVM, Sui MoveVM). Our throughput is also high enough, with most of the chains I mentioned being more efficient than current Layer 2s. So if the problem is not about speed or throughput, it must be about value capture. Who can blame them? Ordering fees are a new revenue model (basically taking all network fees for themselves, rather than sharing with decentralized value extraction validators, just joking, I actually really like validators).
So, revenue sharing, isn't it? This way, all the hassle is solved, and all the benefits are obtained.
Application chains seem to be an engineering solution that exists to solve a problem. Don't get me wrong, the tech-loving part of me really likes it, but as a practical developer, I can't help but ask: why is this the case?
