A more practical solution is to distribute these gas fees to the application.
By Andre Cronje
Compiled by: TechFlow
It all started with a tweet:
Andre Cronje：
Why L2 is not a good application chain for developers:
There is little infrastructure support for deployment, such as stablecoins, oracles, and institutional custody.
Lack of support from foundations or laboratories.
Centralized and vulnerable to attacks.
This leads to dispersed liquidity and the need to rely on bridging.
Lack of user and developer community.
Time is spent dealing with these issues instead of focusing on the application and the users.
Weakening network effects.
There are still long transaction confirmation times (some providers won’t work with you)
Developed alone, without team support.
This experience exposed me to a number of product recommendations, and one in particular caught my eye (among a ton of other cool products of course);
Amazingly, they launched my own app chain in just a few minutes.
This was very exciting to me from a technology perspective as there were a lot of new solutions here that I hadn’t been exposed to before, and I’m always keen to learn new technologies, so I started digging deeper.
The idea of having your own tech stack, complete with native stablecoins, oracles, proof systems, network effects, bridging, and interoperability, sounds too good to be true.
This may sound a bit far-fetched (but not entirely), so I’ll start with what I consider to be the two biggest hurdles: native stablecoin issuance and trusted oracles. Having gone through this process recently when launching Sonic (and spending over $5 million), it’s both humbling and a bit embarrassing to realize that I could get this for free.
Of the many recommendations, noble.xyz is the one that interests me the most because it claims to provide native USDC and CCTP for any IBC-enabled chain. First of all, this is a cool product, but it is not native USDC or CCTP, but a bridge to issue assets through its blockchain and then transfer to other integrated chains through IBC (the interoperability version of the Cosmos ecosystem, which is excellent). This is not automatic, it is not free, and it is not native or CCTP.
That being said, we can also look at other options like LayerZero and AcrossProtocol, which are great protocols. We work a lot with LayerZero, they are amazing, and I highly recommend any chain to work with them, but it's still not a native issuance. I know this is nitpicking, but after going through all the problems with bridges, nothing beats a native issuance in terms of trust and scale. If you want a native issuance, you need to have the funds ready.
On the oracle side, I received recommendations for skipprotocol, storkoracle, and redstone_defi, but unfortunately, none of these products are plug-and-play, 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 be L1 or L2 wants to be in the top 50, 20, or 10 (whether it's trading volume, total locked value, or market capitalization). However, this is not always applicable, and some applications don't need to be that big. I experienced this on the Keep3r network, which everyone expected to be another Yearn, but it was never intended to be. Yearn is similar to an asset management company, while Keep3r is a niche operation and maintenance tool, and the two do not need the same evaluation standards. Therefore, this article is not to belittle the value of these products. As I said, they are all excellent, but if you assume that you want to launch an L2 or L1 application chain to compete with Arbitrum, Optimism, Solana, Avax, etc., these solutions are not comprehensive enough.
Next, we come to developer tools and wallets, which are compatible with any new chain, but users and developers will need to manually configure those RPCs. While this isn’t a big deal, it does add some unnecessary friction.
Finally, we have to mention Blockscout, which is the benchmark for free browsers. There is nothing more to say, they are excellent. However, paid products like etherscan often have an advantage because they have a dedicated paid team.
Of course, this doesn't solve the problem of interoperability or network effects. Take unichain for example, if uniswap was the only application on the chain (although unlikely, but let's assume), how much of its trading volume would it have? How much of its trading volume would be arbitrage with other AMMs, how much would be liquidating positions in the money market, and how much would be other bad flash loan activities? In isolation, transaction fees will be reduced, and it is composability and interoperability that help.
I read a bit about clusters and hyperchains and I admit that either I didn't understand it thoroughly (which is likely) or it just didn't make sense in practice.
Now coming to the last sentence, it doesn’t really make sense. It’s amazing to be able to spin up your own L1 or L2 in a few minutes, complete with browsers, RPC, bridges, etc. But is it really practical?
Take Unichain for example (sorry I’ve been looking at Unichain, I do think they may be one of the few exceptions because they have huge network effects, but stick with me on this example), a big reason they built this chain is to capture value. Check out this tweet:
Uniswap on Ethereum alone has generated $2.439 billion in gas fees for validators. This does not include MEV extraction (which, as a sorter, they can capture). This is $2.5 billion that could have been earned by Uniswap itself, but went to validators. This is a very large number.
So 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, or integrating oracles and local stablecoins? What is the problem we are trying to solve? We want to capture value back into the application, rather than having it taken away by the network. Isn't there an easy solution for this? Isn't this problem already largely solved in our creator economy? The answer is revenue sharing. Platforms like YouTube, Twitch, X, etc. all give creators a share of revenue. So wouldn't a more practical solution be to share these gas fees with the application?
I want to ask, what other practical reasons are there? Of course, the low latency problem is basically solved by modern blockchains (such as Sonic, Avax assuming you need EVM, Solana SVM, Sui MoveVM). Our throughput is also high enough, and most of the chains I just mentioned are more efficient than the current Layer 2. So if the problem is not speed, and not throughput, then it must be a problem of value capture. Who can blame them? Sorter fees are the new revenue model (basically keeping all network fees for yourself instead of sharing them with decentralized value extraction validators. Just kidding, I actually like validators).
So, revenue sharing, right? That way, all the hassles are solved and all the benefits are obtained.
Appchain seems like an engineering solution to a problem. Don’t get me wrong, the tech enthusiast in me loves it, but as a practical developer, I can’t help but ask: why?
