A stakeholder journey maps one class of participant through a token economy end to end: how they arrive, what they have to acquire or lock, what the system asks of them, what they earn and in what unit, and how they leave. It is done per class, because a validator, a paying customer and an early investor experience the same design as three different products. Mapping it before choosing mechanisms is what stops a project from designing an economy that only works for the people who already hold the token.
The exit column is the one most designs cannot fill. If the only way a participant realises value is by selling to the next participant, that is not a journey, it is a queue, and the map is what makes it visible before launch rather than after.
Scroll to see the full diagram
Why stakeholders come before mechanisms
A published token-economy design method puts it first in the sequence: identify the stakeholders, then identify the functions of the token economy, then define the desirable behaviours, then select incentive-mechanism types, and only then specify the mechanisms.1 Mechanism selection is step four of five. Most drafts we read start at step four.
The reason the order matters is that a mechanism is only good relative to somebody. A staking reward that reads as generous to a treasury holder reads as a fee to a customer who has to buy the token before using the product. Without the journey, that second reading never surfaces, because nobody in the room is playing that role.
What each row of the map records
For one class: how they find the system and what they wanted before the token existed. What they must hold, lock or stake to participate, and what that costs them in capital and in time. What obligations they take on, including anything slashable. What they receive, in which unit, on what cadence, and whether it is denominated in the token or in something stable. And how they exit, to whom, at what depth.
The rights and constraints per class are not an unusual thing to specify. Standards-body treatment of token design separates roles such as issuers, holders and validators as distinct technical actors whose properties have to be specified rather than assumed.2 Practitioner tokenomics documentation does the same commercially, separating distribution and vesting terms by class: team, investors, community and treasury.3 The journey extends that from a table of allocations into a description of experience.
The classes that get skipped
Four keep going missing in the drafts we review. The customer who wants the product and has no interest in holding the token, whose journey reveals whether the token is a feature or a toll. The market maker, whose inventory and loan terms decide what liquidity actually looks like at launch. The exchange or venue, which has listing conditions your design has to satisfy. And the person who leaves, whose exit is somebody else's entry and therefore has to be someone.
Mapping the customer class is where the revenue question surfaces on its own. If the customer journey shows a business that works without the token, the token has something real to attach to. If the journey only works because the token appreciates, the design is standing in for a business rather than supporting one.
How we run it
Name the classes first, on one page, before anything else is drawn. Write each journey in the participant's own terms, not the protocol's, so the row reads as what someone does rather than what the contract enforces. Then read the map for two things: any step where a class is asked to take on cost with no matching benefit, and any exit that depends on a new entrant arriving.
Across the 100+ projects we have advised, this exercise takes a day and changes the mechanism set more often than the modelling that follows it. It is cheap because it is done in prose, before any parameter has been chosen, and it feeds directly into the mechanism design document as its first section.
Common questions
What is a stakeholder journey in tokenomics?
It is a map of one participant class moving through the token economy: how they arrive, what they must acquire or lock, what obligations they take on, what they earn and in what unit, and how they exit. It is written per class rather than for a generic user, because a validator, a customer and an investor experience the same design differently. It precedes mechanism selection.
Which stakeholders should a token design map?
At minimum: users who want the product, whoever supplies the network's work or capital, the team, investors, the treasury, market makers, and any venue with listing conditions. Standards treatments separate roles such as issuers, holders and validators as distinct actors whose rights must be specified.2 The class most often missing is the customer who has no interest in holding the token, and that one is diagnostic.
When in the design process does this happen?
Before mechanisms are chosen. A published design method sequences the work as identifying stakeholders, identifying the economy's functions, defining desirable behaviours, selecting incentive-mechanism types, then specifying mechanisms.1 Doing it after the mechanisms exist turns it into a justification exercise. Doing it first changes which mechanisms get built, which is the point, and it costs about a day of prose.
See Tokenomics Design Services for how this applies in practice.
Sources
- Designing a Token Economy: Incentives, Governance, and Tokenomics
arXiv preprint, 2026
Five-step design method beginning with identify the stakeholders and placing mechanism specification last. Read 3 August 2026. - NISTIR 8301: Blockchain Networks, Token Design and Management Overview
U.S. National Institute of Standards and Technology (Lesavre, Varin, Yaga), 2021
Token lifecycle treatment separating issuers, holders and validators as distinct technical actors whose rights and constraints require specification. - Tokenomics documentation
memo.d.foundation, 2026
Practitioner documentation corroborating that tokenomics frameworks commonly separate distribution and vesting terms by stakeholder class: team, investors, community, treasury. Supporting source rather than load-bearing. Read 3 August 2026.
Last reviewed 2026-08
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
100+ projects advised. Complete tokenomics in 4 to 6 weeks.