One of the most influential mental models in crypto investing has been the “fat protocols” thesis, which spawned crypto funds across the world looking to invest in protocols when they were still skinny. For better or for worse, most protocols have been fattening up by being their own projects too.

What is the “fat protocols” thesis?

First presented by Joel Monegro while at USV, it argues that in the blockchain stack, (much) more value will accrue to the protocols than the projects that build on top of them.

Value concentrates at the shared protocol layer and only a fraction of that value is distributed along at the applications layer. It’s a stack with “fat” protocols and “thin” applications.

“Fat Protocols” by Joel Monegro, August 8, 2016

We’ve seen it also this idea adopted by Kyle Samani at Multicoin Capital, when describing value accrual in the “Open Finance” movement (emphasis mine):

…anyone will be able to build local businesses on top of open finance protocols. This is how open finance will enable the un- and under-banked to access financial services. Protocols will not serve consumers. Businesses that navigate local regulations, and provide localized customer service, will serve consumers instead.

“Crypto Mega Theses” by Kyle Samani, April 24, 2019

This thesis makes a ton of sense for investors in the space – the natural way to invest in a protocol is to buy the protocol’s native token. Monegro acknowledges as much, stating that there are “two things about most blockchain-based protocols that cause this to happen: the first is the shared data layer, and the second is the introduction cryptographic “access” token with some speculative value.”

How has this strategy worked?

Without a referendum on the success of the hypothesis (especially only 2-3 years after its formalization), let’s explore how protocols can actually try to convince projects to build on top of them. Their strategies generally fall into 3 buckets, and various protocols have used combinations of all 3:

1. Switch from protocol to a product. (Or at least spend time exposing the protocol in a digestible way.)

Some companies start out as a protocol, moving up the stack as little as possible to gain traction. Some will stop at the API/code template level (0x), while others will move all the way up to consumer-facing UIs (Compound, Dharma).

Nothing too insightful here; this is every tech stack, right?

2. Start an ecosystem fund.

Some protocols that get stuck at the API/code template stage may choose to incentivize others to create their own projects or find their own use cases by making grants from an ecosystem fund. For example, the Ethereum Foundation (EF) has a protocol (that full nodes are running), on top of which there are some APIs or code templates that people can use (Solidity). On top of this, there is an ecosystem fund (Consensys, EF grants) that encourages and funds others to write their own use cases.

The Ethereum Foundation has stopped at the API level but makes grants to other developers who build on top of that API.

3. Design your protocol so that it’s clear how businesses that build on top of you can make money.

Convince other people that they can make money (now or in the future) using your protocol. By selling your vision of the blockchain-based future to entrepreneurial developers, you show them a viable path forward to create businesses that have never existed before. You hope this is inspiring enough to encourage them to build on your platform.

All projects big and small do this, whether in blockchain space or not. Google and OpenZeppelin both have “Developer Advocates”. In blockchain communities, this sometimes takes the form of a “Foundation”.

It’s therefore hard to quantify which projects are doing this (and even harder to distinguish which projects are doing it vs. their VC backers). You could try to estimate based on the # of hackathons they sponsor, # of tweets they send, # of developers on their github… (shout out to Maria Shen who’s been putting together “Dev Reports” showcasing the last of these!)

DeFi project roll call!

Let’s look at the strategies DeFi protocols are using, as composability is top of mind in this particular ecosystem. Note that some have transitioned fully into a consumer-facing product (Dharma, dydx), but they’re included here because of their origins as protocols.

An overview of DeFi projects and their strategies.
  • Maker: MakerDAO used a combination of 1/ and 3/, sometimes putting money behind 3/.
    • The MakerDAO Protocol is exposed via the (Maker-created) CDP Portal to get users to mint DAI. The Maker Foundation then encouraged ecosystem usage of the DAI stablecoin by evangelizing and partnering with other projects to integrate DAI into their wallets, exchanges, etc.
  • Dharma: Dharma seems to have primarily used 1/.
    • The Dharma protocol is exposed via Dharma Lever, their first product. Dharma Lever is a consumer-facing, web-based user experience that allows crypto holders to borrow and lend cryptoassets.
  • Compound: Compound has leaned heavily into 1/, 2/, and 3/.
    • After building a protocol for borrowing and lending, Compound, like Dharma, built a consumer-facing front-end to allow retail individuals to interact with it.
    • They encouraged projects like PoolTogether to use cTokens, a token that results from their protocol. They also launched an ecosystem fund in August 2018 with crypto trading firms, market makers, and hedge funds.
  • 0x: 0x has stayed pretty close to the API/code template layer and used 2/ and 3/ to encourage interaction with their developer toolkits.
    • The 0x protocol is exposed via 2 packages of code snippets, 0x Instant and 0x Launch Kit. 0x Instant allow apps and websites to accept crypto transactions. 0x Launch Kit is a set of code snippets/templates that allow individuals to create their own decentralized crypto exchanges.
    • 0x has an “Ecosystem Acceleration Program” that funds startups and research grants. They also offer infrastructure credits to projects that build on 0x (e.g. AWS cloud credits).

What’s the right strategy, then?

One of the challenges presented by starting with the protocol layer and moving into the product layer is that the platform risk to developers. Knowing that you might move up into products, it’s hard to convince developers that your protocol won’t be modified and specialized to suit the particular needs of your own product, leaving them with protocols with little documentation or support.

Let’s assume most protocol projects end up going the other way: becoming product-first and adopting a “minimum viable decentralization” mindset. This would be akin to the Facebook/Amazon model: building relevant infrastructure first (products), building network effects to support a business on top of it (aggregating liquidity), and then monetizing that infrastructure (open-sourcing to attract other developers, who will use/accrue value to a protocol token).

In the process of becoming decentralized, though, they present another type of platform risk to developers. Without attempting to detail how startups weigh this risk, it’s worth bringing back the emphasis on composability in DeFi. There’s a balancing act between building and delivering products today that work and making sure they will translate to developer needs in the future – especially if you think the most successful projects in the future will be ones that leverage existing protocols today.

(Thanks to Tom Schmidt for helping clarify thoughts around this point!)