AC writes about L2 again: Capturing value back to applications through revenue sharing

Original title: To appchain or not to appchain

Original author: Andre Cronje

Original translation: TechFlow

It all started with a tweet:

Andre Cronje:

· Why L2 is not very reasonable for developers as an application chain:

· There is almost no infrastructure support for deployment, such as stablecoins, oracles, and institutional custody.

· Lack of support from foundations or laboratories.

· Centralized and vulnerable to attacks.

· Leads to decentralized liquidity and requires reliance on bridges.

· Lack of user and developer communities. Time is spent dealing with these issues instead of focusing on applications and users.

· Weakened network effects. There are still long transaction confirmation times (some providers will not work with you) Developed alone without team support.

This experience exposed me to many product recommendations, one in particular caught my eye (there were many other cool products as well);

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

From a technical perspective, this was very exciting for me because there were many new solutions that I had not been exposed to before, and I am always keen to learn new technologies, so I started to dig in.

The idea of having your own technology stack, including local stablecoins, oracles, proof systems, network effects, bridges, and interoperability, sounded really good.

It sounded a bit unrealistic (but not entirely), so I started with the two biggest obstacles I thought of: local stablecoin issuance and trusted oracles. Having gone through this process (and spent over $5 million) recently with the launch of Sonic, it's both humbling and a little embarrassing to realize that you could get all of this for free.

Of the many recommendations, noble.xyz was the one that interested me the most because it claims to provide native USDC and CCTP for any IBC-enabled chain. First, it's a cool product, but it's not native USDC or CCTP, it's a bridge to issue assets through their blockchain and then transfer to other integrated chains through IBC (the Cosmos ecosystem's version of interoperability, which is excellent). It's not automatic, it's not free, and it's not native or CCTP.

That being said, we can also look at alternatives like LayerZero and AcrossProtocol, which are fantastic protocols. We work a lot with LayerZero, they are fantastic and I highly recommend them for any chain, but it is still not a native issuance. I know this is nitpicking, but after going through the various issues with bridges, nothing beats a native issuance in terms of trust and scale. If you want a native issuance, you need to have funds ready.

In terms of oracles, I received recommendations for skipprotocol, storkoracle, and redstone_defi, but unfortunately, none of these products are plug-and-play and require integration, and I am not sure if there will be additional fees. Here, I feel it is 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 is trading volume, total locked value, or market capitalization). However, this does not always apply, and some applications do not need to be that large. I experienced this with the Keep3r network, which was 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, 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 problem, it does add some unnecessary friction.

Finally, block explorers, we have to mention Blockscout, which is the benchmark for free explorers. 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 as an example. If uniswap was the only application on the chain (although it's unlikely, but let's assume it), 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 don’t understand it thoroughly (which is likely) or it doesn’t make sense in practice.

Now 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?

Using Unichain as an example (sorry, I’ve been following Unichain and I do think they may be one of the few exceptions because they have huge network effects, but please stick with me for this example), a big reason they built this chain is to capture value. Take a look at this tweet:

Uniswap on Ethereum alone has generated $2.439 billion in gas fees for validators. This does not include MEV extraction (which they can capture as a sorter). That’s $2.5 billion that could have been earned by Uniswap itself, but it went to the validators. That’s 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’re trying to solve? We’re trying to capture value back into the application, rather than having it taken away by the network. Isn’t there a simple solution for this? Isn’t this problem already largely solved in our creator economy? The answer is revenue sharing. Platforms like YouTube, Twitch, X 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 has been largely solved by modern blockchains (such as Sonic, Avax assuming you need EVM, Solana SVM, Sui MoveVM). Our throughput is also high enough that most of the chains I just mentioned are more efficient than current Layer 2s. So if the problem isn’t speed, and it isn’t throughput, then it’s definitely value capture. And 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-extracting validators, just kidding, I actually like validators).

So, revenue sharing, isn’t it? That way, all the hassles are solved and all the benefits are obtained.

Appchain seems to be an engineering solution to solve 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 is this?

Original link