“There will always be people who are ahead of the curve, and people who are behind the curve. But knowledge moves the curve.” — Bill James
* * * * * * *
The crypto market tends to focus all its time and effort on tokeneconomics — circulating and fully-diluted supply, inflation, buybacks/burns, and dividends. I can’t help but feel that there is a lot of wasted brain power dedicated to this topic, and this time would be far better spent on learning and evaluating protocol business models.
After all, a token is not a business model. A business model is how the protocol plans to generate cash flows, while a token simply entitles owners with a claim on those cash flows. In a mature market, the value of a token will come from the quality and durability of a protocol’s underlying business model. Without a sustainable business model, over the very long-term, the underlying token will be worthless.
If you agree with this way of thinking about tokens, the next question becomes: how do you measure the quality of a protocol’s business model? A good place to start is to first think about the economic attributes of the protocols. Once you have a sense for the economic attributes of your protocol, you can then look at successful companies that have similar economic attributes to your protocol. And although no two companies/protocols are the same, you can look at existing companies for inspiration on how business models that are similar to yours work out in practice.
For example, when I look at the economic attributes of many protocols, I’d argue that the majority of protocols most closely resemble software marketplace businesses. Similar to marketplaces, many protocols provide a service by connecting the supply side to the demand side in order to create new markets.
Let’s take a look at several protocol types below.
Layer 1’s (e.g., Ethereum):
Liquid Staking (e.g., Lido, Stride):
DEX’s and Money Markets (e.g., Uniswap, Compound, Aave):
Over the last few decades, the market has developed incredible frameworks to help teams and investors evaluate the financial health of software marketplace businesses. With the right context, you can map on-chain data into these financial frameworks, benchmark protocols against their traditional marketplace equivalents, and pull best-practices developed by some of the most successful marketplace businesses into your protocol.
Going through this process is incredibly important if you want to build a protocol that will stand the test of time. It will also help you answers questions like:
In the sections below, we’ll walk through the structure of protocol business models and profit and loss statements to give you a sense for how to develop an intuitive sense for your protocol’s business model. (Quick note: the accountants in the room may disagree with some of my classification of certain revenue/expense line items; if you think something should be changed, please let me know).
Before diving deeper, it’s worth looking at the structure of a marketplace’s P&L, how protocol expenses can map to various categories, and key indicators to help you evaluate the quality of your business model. Below is an example of a generic protocol P&L, followed by definitions and examples that are commonly seen when discussing protocol business models.
While on the surface it may seem straightforward, the definition of what constitutes protocol revenue is one of the most debated areas of the P&L. For simplicity, we’ll define protocol revenue as any economic value that accrues to the protocol’s tokenholders.
Examples of protocol revenue include:
While income generated by the protocol that accrues to the supply side is highly relevant, it’s important to differentiate it from direct protocol revenue since supply side revenue does not provide a direct economic benefit to tokenholders. (The most egregious example I’ve seen might be when DEX LP revenue is cited as “protocol revenue”). That said, when the protocol controls the terms of the revenue share with the supply side, it wields a powerful financial lever.
For a simple example of marketplace revenues, let’s take a quick look at Airbnb. The company takes a 3-5% cut of the money hosts make (in addition to the ~10-15% fee charged to renters) — the higher the cut Airbnb can take from hosts, the more leverage it has over its marketplace. We should note the inverse is also true — a marketplace that increases its rake and loses a significant portion of its supply-side is a marketplace with little intrinsic value, and thus, should be valued significantly less than a marketplace that can increase its rake without meaningful attrition on its supply-side.
I suspect there are many cases where protocols are unknowingly overpaying their supply side because they don’t appreciate how much leverage they have over the marketplace. Once projects capture a significant portion of market share, they should experiment with fees to better understand how much leverage they can exert over their supply side.
Examples of supply-side revenue include:
Cost of Revenue refers to the direct costs incurred to provide the product/service to your customers. The expenses that fall into this category range widely depending on the nature of your product.
Though not a perfect accounting definition, these are typically expenses that are (i) incurred in producing or distributing a product/service and (ii) direct variable costs that grow with usage of the product or service. (Note that professional accountants disagree about expense classifications all the time; at the end of the day, expense classifications need to be done in a way that is unique to your project's economic realities).
Below are some examples of cost of revenue commonly seen in protocols:
OPEX captures all other expenses outside of the direct costs you have to provide your product/service. These expenses typically include R&D, general and administrative costs, and costs to acquire new customers (incentives/marketing/advertising).
Research and Development (R&D)
R&D represents the cost to improve the protocol through upgrades, new features, products, and infrastructure. These costs are typically fixed but can increase or decrease based on how aggressive the protocol is in investing in its product offering, chain support, or ownership of the technology stack.
Examples of R&D costs include:
General and Administration (G&A)
G&A reflects the overhead cost to manage the protocol’s operations. Similar to R&D, these costs are typically fixed.
Examples of G&A costs include:
Customer Acquisition Cost (CAC)
As the name suggests, CAC represents the total cost to acquire new customers across marketing/advertising, business development, and incentive programs.
As a general rule of thumb, most software companies aim to earn a gross profit that’s 3x their CAC — for example, if a customer costs $10 to acquire, a well-run company would want to generate at least $30 in gross profit over that customer’s lifetime (i.e., the amount of time from customer onboarding to churn).
Below are some examples of CAC that we commonly see in protocols:
While by no means comprehensive, below are a few key health indicators that we look for across the P&L of a protocol.
Steady, growing revenue (top-line and on a per-customer basis)
COR should grow at a slower rate than revenue
Thoughtful R&D and G&A investment
Efficient and Sustainable CAC
Now that we’ve covered the broad categories of a protocol’s P&L, we’ll walk through a live example and use the above framework to draw actionable takeaways.
Below is a detailed P&L for Lido sourced with data from our close friends at Token Terminal. This represents a combination of on-chain and publicly disclosed expense budgets that can be found on the Lido governance forum.
Lido is a great example for this exercise because its revenue stream is straightforward and fairly predictable, and it’s one of the few protocols that has migrated the majority of its expenses out of the operating company and under the budget of the protocol’s DAO.
If I were the CFO of Lido, I would draw the following conclusions and explore a few actions that could make a significant impact on the protocol's growth.
On paper, the characteristics of many protocols look like software companies on steroids — they often require very little money to launch, allow you to serve customers all over the world, and most importantly, can enjoy economics many companies would kill for: high gross margins.
That said, we’ve noticed that very few teams track their business models and associated financials closely, leading them to make faulty business decisions (such as overspending massively on attracting unprofitable customers). Studying the economic attributes of traditional marketplaces businesses and applying those lessons to your protocol could be the difference between failure and success.
Special thanks to Felix Lutsch, Porter Smith, Hasu, and my finance mentor, Michael Schrader for reviewing earlier versions of this piece.