Introduction
In Web3 (and other software based services), value added pricing models generally make a lot of sense because the costs of operating the protocol don’t increase as strongly with each added user. Unlike in physical industries where the costs of production weigh heavily on your price, online services such as decentralized protocols are often free to use a value added pricing model since they’re primary goal is to optimize for user growth until a threshold of fiscal sustainability is reached.
The primary question throughout all of this is:
Given that we know how much value we’re providing, how much are customers willing to pay for this? And how can we make sure that the revenue generated through that covers the protocol’s expenses in the long run?
This is very similar to a traditional business model. Your protocol has costs that need to be covered by revenue (e.g. development, security through staking rewards, usage incentives, etc).
In an ideal world, the protocol revenue covers these costs, but in reality many new dApps initially run at a loss because they are still finding user traction. This holds especially true in case you require large ecosystem incentives to create a network effect in a multi-sided market, when you have to pay for security as a sovereign chain, or if you decide to run without fees until a user base has been established, for example. Currently, the most common approach is to forward these costs to the future, i.e. you use some kind of emission schedule to pay for staking rewards or incentives. However, as inflation slows down (or token price decreases), protocol revenue eventually needs to pick up these expenses.
Again, this is very similar to the Web2 space where businesses’ primary focus is finding users; profitability generally comes after. Instead of inflationary models, these businesses rely on continuous injection of funds through investment until a profitable threshold is reached.
Future Proofing
Having a sustainable business model in place is essential to the success of your protocol, and as an extension, your token. You should not enter this process blindly. Simply relying on the fact that you know there’s demand for your product does not mean your protocol is set up for longevity. Case in point: regardless of high demand for years, Twitter is yet to be profitable. These types of scenarios are rarely sustainable in the long term.
Without a general idea of how you’re planning to monetize your protocol in the future your team will have a rough time convincing venture funds to invest in your project. As mentioned in the section above, the key question that should be answered is: How and when will the protocol's revenue pick up the expenses?
Managing Your Protocol Expenses
It’s notoriously hard to get a grasp on the cost of each user in Web3. However, a key component that can inform your pricing model is how costs scale when your user base increases because some costs are variable while others are static.
Let’s take a few examples to illustrate this point:
Network Security
In case you’re running a layer 1 chain, you’ll need to pay validators & delegators to secure the network. Expressed in dollars, this is generally a rather static expense as long as the validator set doesn’t grow. Validator operational costs generally vary between 60-800 dollars a month depending on their configuration. However, as per default for Cosmos chains that have inflation enabled, the emission schedule pays delegators a somewhat fixed token amount on each block. This means that if your token price increases you’re effectively paying validators more in USD for what is otherwise a static cost.
If your token economics are set up correctly, and your token value is a function of the usage of the network, your costs (when expressed in dollars) increase with higher adoption. When expressed in tokens, these remain static. This holds true regardless of whether you’re paying for network security through an emission schedule, gas fees, or other protocol revenue.
Customer Acquisition Cost (CAC)
In Web2, startups pay high amounts of money to acquire users through referral fees or other incentive programs as they race to become market leaders. Sometimes even exceeding the Lifetime Value (LTV) of a user. In Web3 similar tactics are used although they are often much less clearly understood in terms of their cost per user.
If your product relies heavily on user incentivization––which is often the case in the highly saturated DeFi environment––it helps to have more data available on the average CAC and user LTV of your protocol so you can adjust incentives to maintain financial sustainability.
Development Costs
In the first stages of your project, development work and operations are usually paid via grants from the foundation that manages the treasury fund that was created during the Token Generation Event at mainnet launch. However, funds deplete, and over time development and operations need to continue if not increase to keep the protocol competitive.
Community pool
The Cosmos SDK comes default with a community pool that receives tokens from the emission schedule, gas fees, and potentially protocol revenue. Depending on how you set this up, this number can increase with the number of active users and revenue your protocol generates.
Conclusion
As you can already tell, these costs (expressed in dollars) are extremely volatile as they’re often directly correlated to the token price. In fact, one could argue that the currently dominant model of fixed token amount expensing through an emission schedule or revenue stream prevents protocols from paying a fair and accurate price for these costs. During bull markets protocols can overpay, yet during bear markets not enough is spent.
This volatility affects long term alignment of critical actors in your network. For example, we’re noticing some validators with relatively low voting power are considering exiting non-profitable networks. As a protocol, you have control over how costs are paid out. Understanding how these expenses scale over time allows you to craft more suitable and sustainable payment mechanisms.
Market Size
Although out of scope for this article, knowing your Total Addressable Market helps you in understanding your potential revenue. In short, you need to research how large the market is that you’re realistically able to serve (your Serviceable Obtainable Market). If you understand the protocol’s expenses, and you know how large your obtainable market is, you can calculate what you would need to charge your users to cover the costs. If that amount is too high, you're not serving a large enough market and you might need to pivot or wait for a better opportunity.
Let’s use another example: imagine you’re building a Cosmos specific Liquid Staking protocol and you’ve got a reasonable and justified estimate that you can capture 20% of the liquid staking market. With your costs in mind, you can now calculate how high of a fee you need to capture on each liquid staking transaction in order to be profitable.
This is an example of cost-based pricing. However, this will likely not be effective because Cosmos is still a relatively small and upcoming market. You’ll most likely find that the user fees required to make the protocol profitable would be too high to convince customers to use your protocol. In this case, you’d generally have to keep your prices low enough to compete and run at a loss until you get to either one of three stages:
► You’re able to capture a larger market share due to a higher value-add (e.g. better UX, lower prices, better marketing, partnerships, etc.)
► Network effect increases to the point where the market size grows large enough (e.g. staking TVL in Cosmos increases substantially)
► You’re able to expand to other similar markets (e.g. Liquid Staking on Ethereum) or you expand your product offering to target other markets (e.g. yield-backed loans).
More often than not, if projects haven’t targeted a large enough market, you’ll find that they will operate on the assumption that at least one of the three above strategies will play out at some point, although there are obviously no guarantees on this.
What’s important is that cost-based pricing can help you understand the financial sustainability of your protocol in the long term, while value-added pricing will help you gain users in the short term.