Andre Cronje's new article: Value capture should return to applications, rather than being taken by the network
TechFlow Selected TechFlow Selected
Andre Cronje's new article: Value capture should return to applications, rather than being taken by the network
A more practical solution is to split these gas fees among the applications.
Navigating Web3 tides with focused insightsAuthor: Andre Cronje
Translation: TechFlow
It all started with a tweet:
Why L2s as app chains don't make much sense for developers:
-
Nearly no infrastructure support at deployment—stablecoins, oracles, institutional custody, etc.
-
Lack of foundation or lab backing.
-
Centralized and prone to attacks.
-
Leads to fragmented liquidity and reliance on bridges.
-
Lack of user and developer communities.
-
Time spent solving these issues instead of focusing on apps and users.
-
Weakens network effects.
-
Still suffers from long transaction confirmation times (some providers won’t cooperate with you).
-
Developing in isolation without team support.
This experience exposed me to many product recommendations, one of which particularly caught my attention (alongside many other cool products):
Surprisingly, they got my own app chain up and running within minutes.
From a technical standpoint, this excited me greatly—there were many novel solutions here I hadn’t encountered before, and since I’m always eager to learn new technologies, I began digging deeper.
The idea of owning your own tech stack—including native stablecoins, oracles, proof systems, network effects, bridging, and interoperability—sounded almost too good to be true.
It does sound somewhat unrealistic (but not entirely), so I focused on what I saw as the two biggest hurdles: native stablecoin issuance and trusted oracles. Having gone through this process recently during Sonic’s launch (and spending over $5 million), I realized how humbling—and slightly embarrassing—it would be to get all this for free.
Among the recommendations, noble.xyz stood out most because it claims to offer native USDC and CCTP to any IBC-enabled chain. First off, it’s a cool product, but it’s not actually native USDC or CCTP. It’s an asset bridge issued by their blockchain, then transferred via IBC (Cosmos’ version of interoperability, which is excellent) to integrated chains. This isn’t automatic, nor free, and certainly not native or CCTP.
That said, we can look at other options like LayerZero and AcrossProtocol—both are excellent protocols. We’ve worked extensively with LayerZero, and they’re fantastic. I highly recommend any chain partner with them. But again, this isn’t native issuance. I know I’m being picky, but after experiencing various bridge issues, nothing beats native issuance when it comes to trust and scale. If you want native issuance, you need to fund it yourself.
On the oracle front, I received suggestions including skipprotocol, storkoracle, and redstone_defi. Unfortunately, none of these are plug-and-play—they require integration, and I’m unsure if there are additional costs. Here, I think it’s important to discuss scale. My assumption is that anyone wanting to launch an L1 or L2 hopes to rank among the top 50, 20, or even 10 (by volume, TVL, or market cap). But this doesn’t always apply—some applications simply don’t need to be that big. I experienced this firsthand with the Keep3r Network; everyone expected it to become another Yearn, but that was never its intention. Yearn is akin to an asset management firm, whereas Keep3r is a niche operational tool—two very different use cases requiring different benchmarks. Therefore, this article isn’t meant to diminish the value of these products. As I’ve said, they’re all impressive. But if you assume you're launching an L1/L2 app chain to compete with Arbitrum, Optimism, Solana, Avax, etc., these solutions fall short.
Then come development tools and wallets, compatible with any new chain—but users and developers must manually configure RPC endpoints. While not a major issue, it still introduces unnecessary friction.
Finally, block explorers—shoutout to Blockscout, the gold standard for free explorers. Nothing more to add; they’re outstanding. That said, paid alternatives like Etherscan often have an edge due to dedicated, funded teams.
Of course, none of this addresses interoperability or network effects. Take Unichain, for example—if Uniswap were the only application on that chain (unlikely, but let’s assume)—how much trading volume would it really have? How much of that volume comes from arbitrage against other AMMs, liquidations in money markets, or malicious flash loan attacks? In isolation, fee revenue drops significantly. It’s composability and interoperability that truly drive value.
I’ve read about clusters and superchains, and I admit—I either didn’t fully grasp the concept (very possible), or it lacks practical significance in real-world implementation.
Now, the final point: while launching your own L1 or L2 in minutes—with explorer, RPC, bridging, etc.—is impressive, is it actually practical?
Take Unichain again (sorry, I keep referencing Unichain—I do believe they might be one of the few exceptions thanks to massive network effects, but bear with me). One key reason they built this chain was to capture value. Consider this tweet:
Uniswap alone on Ethereum has generated $2.439 billion in gas fees for validators. This doesn’t even include MEV extraction (which sequencers could capture). That $2.5 billion could have been earned by Uniswap itself—but instead flowed to validators. That’s an enormous sum.
So, what if we solved this more practically—without needing to run our own chain, explorer, or RPC provider; without forcing users and developers to manually configure RPCs in wallets and dev tools; without integrating oracles or native stablecoins? What problem are we really trying to solve? We’re trying to recapture value back to the application instead of letting the network take it. Isn’t there a simpler solution? In our creator economy, hasn’t this problem already been largely solved? The answer is revenue sharing. Platforms like YouTube, Twitch, and X share revenue with creators. So wouldn’t a more practical solution be to share these gas fees with the applications?
I wonder, what other compelling reasons remain? Sure, low latency was an issue, but modern blockchains have mostly solved that (e.g., Sonic, Avalanche if you need EVM, Solana SVM, Sui MoveVM). Throughput is also sufficiently high—most of the chains I just mentioned are more efficient than current Layer 2s. So if speed and throughput aren’t the issues, it must be about value capture. Can we blame them? Sequencer fees are the new revenue model (essentially capturing all network fees for themselves rather than sharing with decentralized, value-extracting validators—joking, I actually love validators).
So why not just go with revenue sharing? All the hassle disappears, and everyone benefits.
App chains seem like yet another engineering solution built to solve a problem. Don’t get me wrong—I deeply appreciate the technology as a tech enthusiast. But as a practical developer, I can’t help but ask: what’s the point?
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@AndreCronjeTech
