The Fappening

Building The Everything App: Fat Applications vs Fat Protocols

Fat Protocols was written by Joel Monegro in 2016. So far it has been a decent investment thesis (if you picked well), however, we feel in the long term it does not play out so cleanly in terms of protocols accruing the majority of the value created.

Let’s talk about the Fat App (FAPP) Thesis, for which the hypothesis goes:

Most value accrues to an app (or a few apps) that provides a broad range of products.

Although the Web 2 dominant apps were those that started with specialization - they did one thing well. Once attaining a dominant position they leveraged network effects to offer a whole suite of different products to make the most of capturing users:

“Bait them with a tool, lock’em in with the network.”

In crypto, the killer applications and products so far have been those that did many things well, not only one thing great. Binance is the prime example of this, sucking every user and gradually offering every crypto-related product under their custodial umbrella. FTX, with its high-frequency banana trading desk, could have been another one.

From the get-go, the most dominant applications of Web 2.1 are exchanges offering a bunch of services, seemingly a gateway to Web 3. We think the same logic will extend to pure Web 3 on-chain products.

Here is the list of most profitable crypto protocols/applications (both centralized and decentralized):

Option 1 (Fees):

Option 2 (Earnings):

This is the “Fappening”; the flippening of value accrual from protocols to apps (or should we say to an app?). The irony is in the fact that exchanges are not Web 3 apps. They are fully Web 2, permissioned, and centralized yet manage to extract much value from the ecosystem.

We propose two ways how protocols can over time lose their ability to accrue the most value over time to Web 3 native apps:

1. Appchains
2. X, The Everything-app or - as we call it: The Superapp

We define the less common idea of the superapp as the “Wechat of crypto”. It sounds scary but this potentially dystopian vision can become a reality (as expanded below). The internet embraces long tail (or power law) distribution: a dominant player (or two) just like Amazon, and then a very long tail of players fighting for what remains of the market.

But let us pause here and take you waaay back.

History Lesson

Many have written about blockchains as cities, comparing Ethereum to modern-day Manhattan. We think of it differently. Our construction is more primitive and we think of blockchains as religions and apps as towns.

We propose that applications today are like medieval towns, with their place in history still relatively fragile compared to modern-day Manhattan. In our analogy blockchains are religions, and Ethereum is the medieval Catholic Church.

In The Middle Ages, medieval towns were hosted on the protocol of the Catholic Church, rendering them only semi-sovereign in the face of the universal power of the papacy. The papacy was involved in the control of taxation and direction, referencing the Bible as the primary source of tax code, and naturally extracting fees Romewards.

Papatalik in action.

To simplify, what happened next is that a dev named Martin came along, nailed a whitepaper with 95 lines of code on the church door, and a couple of years later there was a hard fork. Some validators joined the new protocol, others decided to stick around.

As a result of this, the applications (cities and principalities) grew more independent and over the centuries the influence of the church over the fee extraction waned. The church still played a role but a notion of nation-states and secularity entered popular consciousness (and the economy).

What we’re trying to say is that the Fat Protocol thesis has not been invalidated yet because we’re very early into the blockchain era aka Web 3. Apps, just like towns, could organize themselves into powerful value-accruing entities just like nation states, diminishing the fee-extractive role of the clergy (chains).

In other words; apps, mostly the supperapp or appchains, will accrue more value in time.

The Appchains And The Superapp X

The appchain thesis is not new and originated in 2016 Polkadot Yellowpaper. It presented a vision of heterogeneous chains with shared security through a common validator set. At that time, one of the alternatives was the heterogeneous vision advocated by Cosmos - every chain of its own, unified by SDK only.

Since then, most have come around to the idea of shared security. Cosmos has altered its direction too. People came to the conclusion that bootstrapping a quality validator set from scratch is hard, and perhaps pointless before a product-market fit materializes. It has become clear that low-quality blockspace is parasitic - it wastes validator resources while utilization in many cases is non-existent.

Appchains are specialized; at a core chain design, they optimize for existing and future use cases that will be built on top of it. Imagine having a liquidity chain that has made all the design choices to favor decentralized finance applications. Such an appchain does not compete for blockspace with other applications and can impose the execution and fee logic most suited for its use case.

In our view, (the best) appchains are good candidates to become the Superapp X. Generally speaking we see it playing out like this:

1. Launch an application on the mainnet of a general chain, demonstrate Proof of Concept, and PMF. Enjoy access to a known user base.
2. If success is achieved go multichain, or better, launch your own execution environment (appchain), where you can exert greater control and capture more of the value. This is an example of dYdX thus far.
3. Abstract all the on-chain aspects and execution environments away and deliver a seamless superapp experience. Find incremental ways to onboard users and add features that make people spend more time and money on the product.
4. Congratulations, you have become X.

Among others, AAVE seems to be attempting to build a superapp in which social meets finance. The marriage of the two can become a strong ~ moat ~ (think credit/social score for uncollateralized lending). Others, like Ribbon, also appear to move in this direction by having their own custom rollup and lending market to accompany the existing option products. The holy grail in both examples is the undercollateralized lending, which is what should unlock the real DeFi 2.0.

Uniswap and Opensea are by far the heaviest applications measured by the fees paid, as we’ve shown earlier. We know how both of them started with one use case at which they excelled. This has allowed them to amass a critical user base of people (and bots) who are willing to pay ultrasound ETH money to use these apps. Since then, we’ve seen both of them acquire NFT aggregators (Gem and Genie) which either solidify the core product (Opensea) or expand the product horizontally (Uniswap).

This is of course a bit of chicken and egg, but once you have the liquidity, you have the users, and once you have the users, you can offer them more products and tailor their experience. One of the ways to do that is to offer your own product wallet to your user base, and improve the user journey (not only better UI/UX, but wallet functionality tailored to the product). Consumer-facing applications that figure out their product suite (the platform) and seamless onboarding of users will win.

If we move away from hyper-financialized use cases, then of course liquidity might not be the critical aspect for the origination of all superapps, but then it’d have to be something else (e.g. in the case of a game - engaging gameplay and economy with an active community of players).

The Trojan Middleware

So far, we’ve described a user-centric approach to developing X. One in which simple DeFi apps with superior UX integrate horizontally with TradFi products and/or other on-chain primitives to gain market share and improve monetization while building a moat. On the technical side, these apps transition from simple smart contract interfaces into full-blown superapps with their own appchains.

An alternative future is that of the Trojan Middleware which gets a warm welcome through the front gates of the applications, bringing gifts of better developer experience and advanced features like account abstraction, frontrunning protections, and MEV cashbacks. The Trojan Middleware is the master of the mempool and uses its access to order flow from applications to dominate block building.

Through block building, the Trojan Middleware is able to provide features that cannot be easily replicated by the application itself, such as chain abstracted transaction execution. This can ultimately result in controlling the point of contact via building a superior wallet/app store experience. Some blockbuilders have already shown the ability to get access to exclusive order flow, on top of which the things we talk about could be built:

There is an alternative to being deceived by the Trojan Horse, though. We think the end state for any aspiring superapp is to become a major block builder itself. This will allow the best user experience for the superapp users, and allow the best guarantees over transaction execution in a manner superapp deems fit.

Just like in web2 major consumer businesses sought to own native payment rails to avoid being locked in by a single provider, so will Web 3 superapps seek to exert control over the execution of their users’ financial intents.

Either way, this is how the Superapp X ends up looking:

The superapp could eventually become a wrapper for Ethereum and other chains while hosting endpoints for all other future “apps” that become a feature of this superapp. Even today, we can think of exchanges as apps wrapping blockchains to allow better UX. Most users need not leave Binance, because so much is accessible from there.

As a crypto-native application, deployment across every reasonable base layer and seamless bridging effectively creates extreme fungibility of the blockspace - commoditization. Optimal pathing for best execution can naturally occur with users not even knowing about the track their execution took. It should go without saying this does have limits. It relies on the assumption that the chains you deployed on are of reasonable enough quality (security).

In this sense, different blockchains provide services to the superapp. Furthermore, an appchain is simply another higher control venue for execution. In this sense, however, the Superapp X would end up becoming a centralized venue.

Users and devs could choose to go directly to blockchains but the supperapp chain abstractor should be superior in many ways:

1. providing cheaper transaction fees
2. smoother app development
3. better UX.

The superapp would become Amazon while users would still have a long tail of blockchains at their disposal that they could use directly just like vendors and buyers use Shopify.

Blockspace Wars of The 2020s

There is an inherent power struggle between applications and base layers. Base layers seek to capture value via transaction fees (even while fees themselves are running to the ground, so the monetary premium is increasingly more difficult to advocate), and offer security and user bases in return.

Successful applications with loyal user bases also seek to capture value themselves and have greater control over how to best serve their users. In other words, the applications now seek what made the blockchains successful - the monetary premium which manifests through demand for the native token.

There are several important pieces in this puzzle - where do transactions happen (point of origination), who controls the block-building process (converting externalities into value capture), what the user intentions are, and who sets the monetary rules?

Transactions, which create value for the chains, originate at the application (or wallet) level. Users desire applications, not blockchains as they are not ideologists but mainly utilitarians. This force inevitably leads to the conclusion of having application-specific chains as an option for execution.

These offer the ability to capture value in a wider array of ways, with greater control over specific design trade-offs which may better serve the user needs than a standardized layer does. Base layers presently have the advantage only in the last factor - the monetary rules. And yet, this is a temporary advantage. To conclude in another history lesson:

In many ways, we can liken base layers to the British Empire and the pound. In the late 18th century, American colonies revolted against British rulers for imposing harsh taxation without Americans having a say in it. This led to the Boston Tea Party and the American revolution - the start of the greatest ‘superapp’ in the history of the world.

Almost two hundred years later, the British Empire crumbled post-WW2, and the pound lost its reserve currency status, giving way to the dollar. This also led to many nations escaping the empire, with India becoming the most notable candidate for the next superapp. This is a real Fappening. If the base layer is exhausted, and the application has the incentive to become sovereign, conflict is inevitable.

It is important to note, similar to global trade post-British empire collapse, these nations still transact. A push towards the Fappening does not mean they will no longer use the original base layers, but rather siphon their ability to capture value for themselves. Demand for blockspace is what drives protocol value capture, and the user endpoint - the superapp - dictates where and what that demand looks like.

This pushes value accrual to the application as the higher degree of optionality means the ability to make profitable decisions more frequently. The Fat App Thesis is real, and in our view, the Fappening (Fat Application Flippening) is the most probable scenario. Someone will come to own a monopoly on composability.

Thanks to thegostep for chiming in.