Use Cases
We see a lot of teams develop solutions to problems without having clearly mapped out specific use cases. This is particularly a concern with broad-scope projects such as generic smart contract platforms, and less so with highly specific projects where a singular use case is taken as a starting point. Without these specific use cases, it’s hard to assess who’s benefiting from your product, how you’re adding value to, and even harder to define how and what you should charge for it.
If you are building a broad-scope product, you should start by identifying narrow use cases where it’s clear who you’re serving and what value you're adding. Taken as a whole, the collection of narrow use cases help you define a narrative around your product that impacts the entire development cycle from initial product and token design to your go to market strategy.
If your ambitions are large, and your product aims to capture value to a large set of users, it can be worthwhile to start slow, and focus on the narrow use cases at first. Once your product is proven to provide value in a smaller market, you can scale and add more use cases over time. The bigger the scope of your product, the more competition you have and the harder it will be to penetrate the market.
A step by step process to establish these use cases:
- Define the problem: Start by clearly articulating the problem your project is addressing. This will help you understand the context and the specific pain points your solution needs to address.
- Research the market: Investigate the existing solutions and identify the gaps or shortcomings in these solutions. This will help you understand where your project can add value and differentiate itself.
- Identify your target audience: Determine the specific group of users who will benefit the most from your solution and understand their needs, ideally through qualitative data.
- Develop user stories: Create user stories that describe how different types of users will interact with your solution. These should outline the user's goals, the steps they take to achieve those goals, and the desired outcomes.
- Identify use cases: Based on your user stories, identify the specific use cases that your project should address. Each use case should outline a scenario in which your solution provides value to the user, describing the user's actions, your solution's response, and the expected outcome.
Your Market And Your Customers
Once you’ve identified your use cases, you can establish whether your protocol is serving a single-sided or multi-sided market.
Multi-Sided Markets
In multi-sided markets, a protocol acts as an intermediary between two or more classes of participants. Osmosis is an example of a two-sided market, where on the one side you have liquidity providers, and on the other you have traders. Multi-sided markets generally require network effects to be successful. For example, without liquidity you can’t attract traders. Knowing what type of markets your protocol is serving helps you identify which incentivisation mechanisms you’d want to put in place in order to get network effect (e.g. liquidity incentives).
Single-Sided Markets
In a single-sided market, a business or protocol is serving a product directly to a single class or participants. A good example is Gnosis Safe, which is a protocol that allows you to create and manage multi-signature wallets on Ethereum. There is no counterparty market that needs to grow above a certain threshold for the protocol to be successful. This can also be understood in terms of network effects as well: there is no added value to users if the protocol gains more traction, a multi-signature wallet functions regardless of network effect. This information is critical to assessing where to assign incentivization.
Note: not all single-sided markets are free of network effect. For example, for each user added to an instant messaging platform, the value for other users increases through same-side exchange benefits.
With a solid understanding of the markets your protocol is serving, you’re able to define who your customers are and start to think about how much value you’re providing to them.
Quantifying Your Value
In value-added pricing, it’s important to research your market and get a rough approximation of what a customer stands to gain from your protocol. This can be either direct monetary gain in the case of certain DeFi protocols, but oftentimes the benefits are indirect and harder to quantify. Let’s take a few examples where we look at the use case and how we use it to define the value add:
Liquid Staking
► Category: easy to quantify
Liquid Staking is a great example of a narrow scoped use case. It allows delegators to keep their staked assets liquid. The direct and obvious benefit for these users is the potential higher yield.
Because of this clearly defined monetary benefit to users, pricing can be easily approached by asking: if a user stands to gain 50 - 100% on their returns, what are they willing to pay for that?
User benefits:
► Before liquid staking, a user could get either 10% APY on staking their tokens or 20% APY by depositing them in a pool. The value add of liquid staking is clear, they are now theoretically able to get a total of 30% APY.
► A less obviously quantifiable value comes to chains as well: a DEX benefits from a potentially higher bonding-ratio to increase the chain’s security as well as the added liquidity in their pools.
Decentralized Cloud Computing
► Category: moderately easy to quantify
Protocols like Akash Network provide a marketplace that lets users buy and sell computing resources. Users can rent or offer a server on the network at competitive prices. For both user types there are clear advantages that provide a value-add over centralized cloud solutions.
Because cloud computing is a highly saturated market and the protocol is competing with a plethora of traditional services, the value-add is derived mostly from how the product stands in relation to existing solutions.
Although the benefits of decentralization are hard to quantify, the pricing difference allows you to easily measure the value-add. The complication in this instance is that the pricing is dependent on the open market between users, which is hard to accurately model before the protocol launch.
User benefits for cloud consumers:
► Pricing: because of the open marketplace, pricing tends to be highly competitive v.s. traditional cloud computing solutions
► Decentralization: users do not have to rely on single entities for their cloud services and can increase redundancy
User benefits for cloud providers:
► Reduced barrier to entry: smaller businesses have an opportunity to participate in the cloud marketplace without having to scale to a size of traditional cloud providers
► Access to new markets: both small businesses and enterprise organizations can interact with the early adopter Web3 native user base and grow in parallel with the network over time
Interchain Security
► Category: hard to quantify
Interchain Security enables blockchains to obtain network security from the ATOM token. Instead of needing to reach a significant market capitalization itself, these “consumer” chains benefit from the relatively high market cap of the ATOM token. In return for this, these chains pay a fee to Cosmos Hub (i.e. ATOM holders).
User benefits:
► Consumer chains require no validator set to be bootstrapped and enjoy a higher security than most new chains would. Chains save on staking rewards, although it remains hard to assess what that amount would be because networks have widely varying costs associated with their security
► An additional and much harder to quantify value-add is the branding association with the Cosmos Hub
Running this service brings risk to the ATOM holders themselves, who are expected to earn something in return. In a sense, Interchain Security can be considered a two-sided market with chains and token holders on both sides. Delegators and Validators stand to gain two things:
- Receiving payments from consumer chains either in the form of transaction fees or protocol revenue
- A potential ATOM value increase due to the consumer chain providing a service or value add to the Hub or increasing demand for ATOM tokens as gas payment
As you can tell, quantifying the exact value-add in this case remains difficult. The unique approach that the Hub has taken is to let the market decide on a suitable price. Chains have to request their admittance as a consumer chain through governance while token holders assess whether the value-add is significant enough. In a sense, the governance platform itself can be seen as an open bidding marketplace between token holders and candidate protocols.
In Conclusion
There’s no one-size-fits-all process that we can apply to each project as each product quantifies value in completely different ways. The key takeaway is that the value-add pricing model requires you to have some kind of approximation as to how much your product benefits a user. In cases where this is hard, your user stories help you take the perspective of your customer and enable you to more closely guess how much they are willing to pay for your service.