Mapping Stakeholders to the Demand-Side Objective Function
Friday, August 4th, 2023
In Demand Side Token Design I made a some, but critical, nuance around thinking about the objective function of a protocol as increasing demand. The nuances are around how constraints are set, as well as getting clear on what the objective function is in terms of scope (wide enough to accommodate different use cases) but also precision (token price as a constraint to an overall utility).
In order for the protocol to grow, we want to map out the core levers, the "sub functions" that are inputs into the objective function.
I looked at possible levers to grow the consumption of the data services we are using in the example.
Already, we saw how the complexity of the model began to expand just trying to model one demand-lever.
The objective function, constraints, and the levers of growth form the initial skeleton of the system design.
However, key to this are the different players who, themselves, have their own objective functions. If they are playing a different game or exploiting the existing functions, the protocol may not succeed.
The well-designed protocol acts as a dynamic check-and-balance against all the different stakeholders, herding them along to maximize the protocol's objective function.
To do this, we need to understand the different personas. In this regard, the exercise is similar to traditional Product Management.
However, I believe the canvas of personas is much broader, and the different shades-of-grey of a given persona matter in ways that are often not deeply considered in traditional web2 ecosystems.
Stakeholders
In this map of stakeholders in the data indexing protocol, I use areas to suggest that a given category of stakeholders may have within them a range of stakeholder personas.
Getting too granular would be ineffective, but I think illustrating them visually helps to shape the conversation.
For example, the Core Developers are firmly entrenched in strong interest and positive alignment. There is unlike to be any cross over into another quadrant, such as weak interest and negative alignment, for example.
Nevertheless, it's still a range. While we may not in the beginning need to think about the ranges and possible personas within the category yet, placing it as an area helps keep in center that, whatever the protocol does, it should also ensure core developers stay in that top-most part of the quadrant rather than taking their position for granted.
Delegators, the ones who stake, illustrate a case where the positive alignment comes from owning the protocol token. But the interest can vary: some may be purely transactional, and hold across many tokens. Some may be especially vested.
And while alignment is mostly positive, the range suggests some may be positively alignment from a missionary perspective; while others might be aligned as mercenaries.
This is an important distinction when it comes to incentives, and understand what attracts whom is a design point in the protocol.
To me, looking ahead and how we ultimately want to drive demand, I am interested in Networks, each of which have ecosystems of users and developers of their own; and the actually dApp developers who will be consuming the data through their applications.
Stakeholder Definitions
The above map gives a sense of the order and inclinations of the different potential stakeholders.
While there are always more granular ways to build out the persona for each one, here are three attributes we can call out for each stakeholder:
- value they provide
- goals (what do they most want; their own objective function)
- token based incentive / mechanism
| Stakeholder | Value they provide | Goals | Token Based Incentives |
|---|---|---|---|
| Core developer teams | Improve the protocol and supporting software | Build viable business | More Token rewards; increasing Token value |
| Indexers | Computing services to index and serve data | Build viable business | Token rewards for net profit |
| dApp developers | Build app using the data services and paying query fees | Build viable business; lots of users; low fees | Earn Tokens to reduce query fees |
| Delegators / Stakers | Increase return on investment | Earn Token; increase Token price | |
| Curators | They provide curation signal on quality data to be indexed | ||
| Subgraph Developers | Build the subgraphs by selecting network and data schema indexed | ||
| Consumers | End-users of the dApps | ||
| Fishermen | Detect fraudulent behavior, specifically be data | ||
| Networks | The ledgers and ecosystem of on-chain data and developers | Increase adoption of network | Prefer own Token to be used |
I haven’t see them listed as stakeholders with goals and mechanisms, but adversaries are an active persona I think we should factor in.
- Data attacker: intending to poison the data
- DDoS attacker: prevent the service from working
- Data fraud: manipulating the data to commit fraud
I didn't fill out everything, but looking at the graph, feel again that the two core Stakeholders (the hardest, as well, to incentivize) are the dApp Developers and the Networks themselves.
To me, being able to zero-in on their goals (their own objective functions) and tying to levers of growth (Demand Side Token Design - Sub Functions) can shape the protocol in key ways.
There may be very little that can be done. These two personas are likely the hardest of all to influence, but designing not just the token but the entire experience of the protocol around these two yields very impactful results.
Lots of similar thinking and foundations found here:
TokenWork: Introducing the Token Utility Canvas (TUC) | by Marc Ziade | Medium