Demand Side Token Design - Sub Functions

Monday, July 31st, 2023

What are the protocol "levers" that contribute to demand growth objective function we described in Demand Side Token Design?

This is, of course, in addition to traditional growth mechanics: communications, events, onboarding, community forums, and partnerships. This is asking with the protocol, itself, can be designed such that the Primary Customer grows on the demand side.

Who is the Primary Customer?

This is often clearer for non-decentralized products since they control the supply side. Many blockchain products have built supply first, which can often be necessary to attract the initial customer. But once the supply has been built, they still have an overall Go To Market motion to drive the demand.

The Primary Customer for a protocol with multiple stakeholders is the customer who pays for the service rendered by the protocol.

The overall Objective Function of the protocol should drive growth of this user. The clearer it has been set, along with the Constraints, the clearer the initial mental model of its growth can be.[1]

It's potentially possible there isn't any: the nature of the supply-side acquisition by the protocol solves a deep enough problem that growth is product led or can easily be performed through BD.

But this essay is addressing the base case where that isn't the case.

So if we use the illustrative case of a protocol that provides data indexing services, the Primary Customer will be the one who would pay for access to the service and pay for the volume.

If there is not enough demand, the protocol will not be sustainable. Therefore, thinking about the revenue model or sustainability model up should be foundational.[2]

In the case of the data indexing service, the Primary Customer is that dApp builder who wants access to the data. The dApp builder has his own primary customer and users, and those could vary in personas and business model.

So let's start with the primitives around a single dApp builder and think about what drives their consumption.

This may seem very basic; but decomposing what we take for granted and then building upon it can help us unlock areas of focus.

Starting with Customers, the flow of Customers to the dApp is a direct input to some function which will drive the revenue. We will look at the different elements of the function later.

At the same time, the volume of the data service consumed is the spend by the dApp. That's also subject to some function with other inputs, but nets out to the spend.

dApp as a primary customers and, in many ways, a primary Agent in our system, want to maximize their Profit.

The dApp's Objective Function is "maximize profit from the dApp" and the levers for them are to increase the flow of Revenue and reduce the amount of Spend.

If the Objective Function of the Protocol is to maximize the usage of the Data Service, we see some potential levers:

This second input was NOT modeled above, but the question begs itself in its absence as we focus on the objective function of increasing the flow of Data Service.

One of those could be the price of the data service.

While lowering price does not always increase demand,[3] it seems relatively safe to assume in a b2b context, lower price will not hurt demand, and could increase demand.

This then introduces one of the constraints, which is sustainability: we don't want the objective function to pull a Paperclip Maximization, and drive the price to 0.

What did I add here?

This introduces a new element outside of the dApp, but I wanted to add it since I brought up the issue of price going to zero to drive demand (free is great marketing for customer acquisition).

Indexers are those node operators providing the data indexing service that dApps need.

So if the price goes to zero, potentially Indexers churn off the service, rendering no service.

Here are some of the dynamics:

Other potential dynamics that could be modeled to incentivize more demand (which can be stimulated by lower prices) but that must be kept in check by the number of indexers available (which we want to be high).

This is more of a Supply-Side issue, so I'm going to park here and continue on the Demand Side.

Let's riff on what else can increase the demand for a single dApp provider:

These feel like good sub functions to maximize: get more customers, and for each customer, increase the usage.

So let's drill into potential ways to stimulate demand for each through incentive and interface design (again, assuming there is product-market fit):

More customers could come from:

More data usage per customer could come from:

Levers In Control

So let's consider whether some of these levers can be modeled as part of the protocol.

After first glance, the nature of the dApp business seems like it would not be something that can be influenced. And likely any influence would be weak. But it's not impossible.

For example, "Increase pool of potential customers" is a value of traditional marketplace design, like Apple's App Store. The App Store attracted potential customers, which attracted the Developers. Developers attracted more users, which attracted more Developers.

There was definitely intention around building the marketplace.[4]

Could this concept be incorporated into the protocol? I think it's possible to at least model it and then think about the protocol/product mechanics, especially since there's existence proof this works.

What about "increase word of mouth" or referrals per customer?

We already see these succeed in traditional businesses, whether passively with a logo on the web page to more active referral systems. This could also be incentivized by the protocol.

Similarly, repeat usage from existing customers could be incentivized as long as the data and UX were good. A simple approach is built in volume credits; as usage or velocity of usage increases, price goes down. What is exciting about crypto is that those incentives could be automatic, and have multiple inputs (such as time, volume) that can become part of the dApp providers own business model.

I mentioned this in the first essay Demand Side Token Design that no amount of incentive design can make up for a crappy product. So I'm going to address some of those foundational issues briefly since they are Product Management 101.

To continue to thought experiment, in the next essay I am going to drill further into Protocol Design to Incentivize Demand

  1. I think Bitcoin may be an example where the Primary Customer has shifted, yet it continues to grow. The Primary Customer was probably the one seeking to transfer money. But now the primary customer who pays for the service is one who seeks a Store of Value. Or maybe that was the plan all along. ↩︎

  2. The Web3 Sustainability Loop. A system design for long-term growth of… | by Trent McConaghy | Ocean Protocol from Trent McConaghy addresses this by adding different revenue models from web2 into the equation, as well as introducing the concept of countries having their own sustainability model. ↩︎

  3. Two examples are Giffen goods, which are inferior goods, often staples, that rise in price, creating a substition effect that drives demand; Veblen goods increase demand due to status or quality price signaling (higher price means higher status which increases demand) ↩︎

  4. How to grow a protocol | Dan Romero (Co-founder, Farcaster) - YouTube Dan Romero of Farcaster uses the Apple App Store illustration and provides more details ↩︎