Protocol Economics: Ignore at Your Own Peril

“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): 

• Product: censorship-resistant blockspace for decentralized applications 
• Supply side: validators that maintain the censor-resistant network 
• Demand side: developers and end-users of applications that use blockspace on the network 

Liquid Staking (e.g., Lido, Stride): 

• Product: access to staking yields while retaining liquidity 
• Supply side: validators that run nodes on behalf of depositors
• Demand side: depositors that want to stake without running a node 

DEX’s and Money Markets (e.g., Uniswap, Compound, Aave): 

• Product: ability to trade, borrow, or lend tokens permissionlessly
• Supply side: liquidity providers 
• Demand side: users who want to trade, borrow, or lend 

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: 

• Is our business model economically sound?
• Should we accelerate growth or slow down and recalibrate?
• What levers should we pull to accrue value to the protocol?

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). 

Overview of Protocol P&L's

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.

Revenue

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:  

• Layer 1s: burn mechanisms based on gas consumption. 
• Appchains: mechanisms to internalize MEV. 
• Liquid Staking: staking commission fees accrued to the DAO. 
• DEX’s: take rate on trading fees. 
• Money Markets: net interest income. 

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: 

• Layer 1’s: transaction fees and MEV proceeds paid to validators
• Liquid Staking: staking commission fees accrued to validators
• DEX’s: trading fees accrued to liquidity providers
• Money Markets: interest income accrued to depositors      

Expenses: Cost of Revenue (COR)

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: 

• Token issuance to Layer 1 validators
• Cost of posting data to Layer 1’s (e.g., rollups incur a cost to post transaction data to the L1)  
• Software ops and maintenance (e.g., teams that are paid to monitor the protocol and facilitate any critical off-chain functions)   
• Oracles (e.g., lending protocols need to pay oracles for data feeds that inform potential liquidations)

‍Operational Expense (OPEX) 

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: 

• Development of upgrades, new features, or products. 
• Research/development related to expanding to new chains. 
• Migration to an appchain or app-specific rollup.
• Grants paid to teams to outsource core protocol development.
• Security audits for new features or upgrades. 

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: 

• Finance function
• Legal and compliance
• Human resources
• Rent

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:

• Liquidity incentives for LP’s or depositors.
• Referral programs.
• Incentivized business development partnerships.
• Paid marketing for sponsorships or ad campaigns.  

Key Health Indicators

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)    

• Steady growth and predictable revenue streams.
• Revenue per customer increases over time. This could come from increased usage of the product and/or cross-selling additional products.
• Once a protocol has acquired significant market share, protocol revenue should grow at a faster pace than supply side revenue. This can be a sign of the protocol having leverage over its supply side.     

COR should grow at a slower rate than revenue

• You want to make sure that the incremental cost to service new customers is growing more slowly than the amount of revenue that these new customers generate for your protocol. Said differently, the cost to service your 10,000th customer should be significantly less than the cost of servicing your 100th customer. If revenue grows/stays flat while cost of revenue falls with each new customer, margins will improve (this is often referred to as “margin expansion”). 

Thoughtful R&D and G&A investment

• Evaluating R&D spend is more of an art than science. For early stage projects, you want to see aggressive R&D spend in opportunities that can generate a high return on investment (we discuss how to measure return on investment in this piece). 
• G&A is also very qualitative, but you should continually evaluate this category to avoid unnecessary overhead expenses that could better be invested into the growth of the protocol.   

Efficient and Sustainable CAC

• It’s not rocket science, but any business that pays more to acquire customers than it can generate in revenue from them is a bad business. 
• Some companies can afford to have very high acquisition costs because they have sticky products, high switching costs, and can earn very high margins on customers. These companies can spend more on acquisition because they earn many times more than they paid to acquire their customers. On the other hand, companies that have lower margins, low switching costs, and higher churn need to be far more efficient with their acquisition spend. 

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. 

‍Lido P&L Analysis and 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.    

Revenue 

• Continue to invest in the growth of ETH staking through expanding support for L2’s and continue with integrations to grow demand for stETH.
  
  
• On an ongoing basis, convert a portion of revenue into USD to match USD-denominated expenses. (We don’t believe projects should be managing their assets like a fund would by betting on the price of ETH/crypto to go up).
  
  
• Explore ways to implement a dynamic revenue share with validators, with larger validators getting a smaller percentage cut and smaller validators getting a slightly large cut. This may become more important with the introduction of the staking router, which will enable Lido to support many validator sets, including those that are permissionless. It’s possible that the sets with the largest validators would accept a smaller revenue share, while permissionless validators would require a higher revenue share to support their cost structure.
  
  Building on the above hypothesis, Lido could consider introducing a form of market-driven pricing for the largest validator sets. In this approach, validators could submit the lowest fee that they are willing to accept in order to receive a higher share of new deposits. If the hypothesis is correct, the competition for deposits would lead to the largest validators taking a smaller revenue share. The resulting increase in protocol revenue could be used to subsidize the smaller permissionless sets and/or deployed to grow the protocol in other ways. While this idea deserves more research, it has the potential to increase the decentralization of the Ethereum network while also improving the economics of the protocol.   

Gross Margin

• With a gross margin of ~89%, Lido looks like a very healthy SaaS marketplace business. (SaaS businesses aim to achieve above 70% gross margin and Lido is well above that benchmark). 

CAC

• While incentive spend is decreasing rapidly, LDO-denominated CAC is still very high at its current rate (~$1m LDO per month). That said, enabling withdrawals has already reduced LDO acquisition expenses — between February and May, Lido decreased its monthly LDO incentive spend by ~75%.
  
  
• Although the referral program is in the process of being retired, Lido was wise to transition to a DAI-denominated referral program model. It’s very difficult to design an efficient and predictable acquisition model when the CAC and associated revenue are both denominated in volatile assets (LDO and ETH). Lido should keep this in consideration as it designs a new growth model to replace the referral program. And over time, Lido should explore a similar approach for liquidity incentives. 

Summary

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.