The Fat App Thesis: An Inflection Point in Value Accrual

Intro

To set some context for this report I’d recommend checking out my last report on the Scaling Paradigm: https://arcanaresearch.substack.com/p/the-scaling-paradigm-whats-happening

In that report we covered the dynamics of Ethereum’s scaling dilemma and value accrual via the rollup-centric roadmap. In this report we’ll touch on additional factors that further widen the value accrual gap and transition us from a predominately Infra-dominant landscape to an app-centric one. 

In the last report we alluded to the idea that all infra (or at least functions of the infrastructure layer) will inevitably trend to zero – this was certainly the case with DA (data availability). There are many trends that have accelerated this: app-specific sequencing, private order flow & MEV capture, and the rise of app-chains/vertical integration.

The idea is that we will see a transitioning effect from the “Fat Protocol Thesis” to the “Fat App Thesis”.

The goal of this report is to elaborate on the topic of the ongoing value leakage from ETH (and in a broader context, crypto infrastructure as a whole), as the protocol layer. The primary focus then was the direct relationship between Ethereum and L2s, and the concerns of value accrual brought on by the blob fee market. The focus of this report is on the direct relationship between the apps and the L1. We’ll use Ethereum for the broader example throughout the report, however, it’s worth considering that these concepts broadly affect all L1 protocols if our thesis proves to be true.

Some terminology clarifications:

Protocol Layer – The term “Protocol” is generally used loosely within a broad context in crypto, usually covering any set of rules or standards that define how data is exchanged and executed. For the sake of clarification, we will refer to “Protocol” as simply the infrastructure layer (Ethereum, Solana, L1s, etc.).

Application Layer – Self-explanatory. Products that users directly interact with (Uniswap, Jupiter, Pump fun, etc.).

Was The Fat Protocol Thesis Wrong?

In 2016, Joel Monegro introduced the Fat Protocol Thesis, which suggests that in crypto networks, most value accrues at the base protocol layer (Ethereum, Solana) rather than at the application layer. This is fundamentally different from the Web2 paradigm, where applications like Facebook, Google, and Amazon capture most of the value, while protocols (e.g., HTTP, TCP/IP) remain commoditized.

The Fat Protocol Thesis was indeed correct, at least over the last eight years. This can be seen with the wide discrepancy between valuation multiples to earnings with infrastructure vs applications. On average, applications continue to trade at massive discounts relative to their earnings when compared to infra. The following graph by Syncracy Capital perfectly illustrates this: ETH trading at over a 300x multiple relative to its revenue, compared to MKR (now Sky) which is only trading at a 6x valuation to earnings.

Source: syncracy: application-fee-capture

Under this model, infrastructure within crypto has amassed generous amounts of funding and VC capital. In fact, this has been so much the case that founders and builders are almost incentivized to launch another alt-L1 or general-purpose rollup, knowing VC capital will be waiting to fund them. Now, this isn’t a knock on crypto infra, but rather a need to shift perspective briefly to illustrate what’s really going on. That topic is what I view as the invalidation of The Fat Protocol Thesis, and a mirroring of what inevitably happened within Web2.

In our last Scaling Paradigm report, we mentioned how DA (data availability) was becoming commoditized and inevitably trending to zero. On the same premise, we can assume that likely all parts of the infrastructure stack will eventually become commoditized and ultimately extracted away. The reason for this?

1.       The Fat App Thesis – Applications are realizing that they can capture more value by becoming sovereign “appchains” and verticalizing the entire stack.
2.       App-Specific Sequencing – Apps are in control of their own transaction ordering and inclusion process. This is the alternative route for apps that don’t want the overhead of bootstrapping their own app-chain from scratch.

The Fat App Thesis

The Fat App Thesis argues that successful crypto applications will capture more value than the underlying blockchain protocols. The simple argument for this is: applications are businesses, and businesses prioritize maximizing revenue. We covered this topic at length in the last Scaling Paradigm report as it pertained specifically towards rollups.

In that case, rollups were simply acting within their own incentivized behavior when it came to paying minimum blob fees – an approach any reasonable business would pursue. When blobs were <50% utilized, fees remained static/ low. Inversely, as blobs grew to >50%, fees began to increase at a rate of ~12% in the proceeding block, prompting L2s to prioritize blobspace utilization. In many cases, some rollups even switched off from posting data directly to blobs.

The question is: what is stopping apps from similar tactics to maximize value capture and minimize value leakage?

Some of the most successful apps in the space are the ones actually generating consistent revenue, such as: pumpfun, Hyperliquid, Jupiter, and Uniswap. The common feature with all of them? Fee Revenue. It only makes sense for these businesses to want to control their own orderflow and MEV capture, or in many cases, become a sovereign appchain.

Vertical integration seems to be the most economically efficient direction for apps looking to plug that value leakage. The opportunity cost of not doing so only grows as the application grows. This is great for apps, not so much for underlying infra like Ethereum. We’re already seeing the tell-tale signs of this with Unichain and JupNet.

App-Specific Sequencing & Orderflow

App-Specific Sequencing refers to a blockchain design where an application has control over its own transaction ordering and inclusion process rather than relying on a general-purpose shared sequencer (like Ethereum or an L2s default sequencer). The Fat App Thesis and ASS (app-specific sequencing) are directionally correlated, in that apps are in control of their orderflow and MEV capture under both these concepts to a degree. In this context, we can even say that The Fat App Thesis is simply the manifestation of applications adopting app-specific sequencing at scale.

There are a couple of key aspects of app-specific sequencing worth noting:

Control Over Transaction Ordering – Generally, applications are reliant on Ethereum’s mempool or an L2s sequencer in determining how transactions are ordered and included into blocks. ASS removes this function away from the protocol layer and allows the application itself to determine the ordering sequence. This allows apps to prioritize transactions based on custom logic rather than default first-come, first-served models. Now, although the FCFS model may be simpler in design, this leaves the door wide open for the common vulnerability of frontrunning and MEV we see much too often in the space. This leads us to our second point:

Custom MEV Mitigation – Because the transaction ordering is now in the control of the application, it becomes much easier to implement custom logic to mitigate MEV. Apps can prioritize transaction ordering based on many different conditions:

• Bid-based ordering: highest fee or auction-style selection
• Fair sequencing: batching transactions to reduce frontrunning
• Time-based commitments: ordering txns based on timestamp commitments

MEV alone is a substantial source of revenue. It makes sense for applications to mitigate MEV, not only to capture the value flow but also direct it where it benefits the apps the most. Incentivizing LPs, traders, and stakers of an application with redistribution of MEV revenue is