Token Utility and Value Accrual Frameworks

Before you touch a spreadsheet of supply numbers, you have to answer a harder question: why should this token exist at all? Every durable token design starts from a small set of utility frameworks, and almost every failed token skipped this step and went straight to "how many do we mint."

There are four broad buckets a token can fall into, and most real tokens are a blend of two or three:

1. Medium of exchange / gas — the token is required to pay for a service (transaction fees, compute, storage). Demand is mechanical: you cannot use the network without it. ETH on Ethereum is the clearest example — every transaction burns or pays gas in ETH, so usage directly creates buy pressure.
2. Access / utility rights — holding or spending the token unlocks a feature, tier, or product (API credits, premium analytics, in-game items). Demand tracks product usage, not speculation, if designed well.
3. Governance rights — the token lets holders vote on protocol parameters, treasury spend, or upgrades. Governance alone is a weak value-accrual mechanism because voting rights don't pay anyone a cash flow; they only matter if governance controls something valuable.
4. Value-accrual claims — the token captures a share of protocol revenue through mechanisms like fee distribution, buyback-and-burn, or staking yield funded by real income. This is the closest a token gets to behaving like an equity claim, and it is also the bucket regulators scrutinize hardest (see Module 7).

The practical design test is this: "What does holding this token let someone do, and why would demand grow as usage grows?" If you can't answer in one sentence without the word "hopefully," the utility isn't real yet. A token that only exists because "we need something to sell in our round" has no utility framework — it has a funding mechanism wearing a utility costume, and both your community and regulators will eventually notice the difference.

A useful mental model is the decision tree: first ask whether the token is required for the core action (medium of exchange) — if yes, you have mechanical demand. If not, ask whether it unlocks a specific right (access or governance) — if yes, demand depends on how valuable that right is. If neither, ask whether it accrues a share of cash flow — if yes, you're building something that behaves like a security in most jurisdictions and must be structured accordingly. Mapping your token against this tree before writing a single line of supply-schedule math prevents the single most common failure mode in token design: bolting utility language onto a token that was designed purely to be sold.

Worked Example

Compare three tokens against the framework:

• Ethereum (ETH): Pure medium-of-exchange/gas utility. Every smart-contract call and transfer consumes gas paid in ETH. Demand is mechanically tied to network usage — more activity, more ETH burned (post-EIP-1559), regardless of sentiment.
• Uniswap (UNI): Historically governance-only. UNI holders vote on treasury allocation and protocol parameters, but for years the protocol fee switch sat off, so UNI captured no direct cash flow. Its price action tracked speculation on future fee capture more than present utility.
• Hypothetical SaaS-token ("DataMesh"): A token that captures a fixed percentage of subscription revenue, used to buy back and burn supply monthly. This is a value-accrual design: demand is tied to the business's actual revenue, which makes it easier to model (Module 4) but also pushes it toward security-like treatment in the US (Module 7).

Each design choice cascades into every later module: utility shapes vesting incentives (Module 2), who should receive allocation (Module 3), how you'd value it (Module 4), and how regulators will classify it (Module 7).

Exercise

Using the framework above, pick three tokens you know well (they can be from your own watchlist or well-known projects) and classify each one:

1. Which bucket(s) does it fall into — medium of exchange, access/utility, governance, or value-accrual?
2. Write one sentence per token answering: "What does holding this token let someone do, and why would demand grow with usage?"
3. For the weakest of the three, write two sentences explaining which mechanism is weakest and why — is it governance without a treasury worth governing, or access rights nobody wants?

Save this classification — it becomes the seed input for designing your own project's utility in Lesson 5 (Design Your Token's Utility), where you'll apply the same decision tree to your own token from scratch.

Recap

• Token utility sorts into four buckets: medium of exchange, access/utility, governance, and value-accrual — most real tokens blend two or three.
• The design test is one sentence: what holding the token lets someone do, and why demand grows with usage — vague answers mean the utility isn't real yet.
• Your utility choice here determines every later module: vesting incentives, distribution recipients, valuation method, and regulatory classification.