Token Utility 101

What token utility actually means

Token utility is the most overloaded word in tokenomics. Founders use it to mean different things, often within the same whitepaper, and almost any token on a public chain can claim some version of it. The result is that "utility token" tells you very little about what a token actually does.

The useful question is narrower: what can a holder do with this token that they cannot do with any other one? That is true utility. Holding ETH gets you blockspace on Ethereum, no other token does that. Holding HYPE gets you the right to launch new perpetual markets on Hyperliquid, no other token does that. Holding a generic ERC-20 governance token usually gets you the right to vote on proposals that nobody else cares about, which is utility on paper and very little in practice.

Payment is the case I have to address up front, because founders confuse it with utility most often. A token accepted as payment for a service is not, by that fact alone, a utility token. Almost any liquid asset can serve as a means of exchange, including stablecoins, the project's competitor token, or fiat. If the only thing the token does is sit in a checkout flow, the project does not have a utility token, it has a payment rail. That is a different design problem with different value capture properties.

Good token utility is related to users doing real work on your platform or protocol. Anything else is decoration, and most projects ship a lot of decoration.

The six categories of real token utility

When I read a whitepaper claiming utility, I check it against six concrete categories. These cover almost every token I have seen that has a defensible utility argument.

• Gas or fee payment. Used to pay for on-chain actions. Almost always limited to L1 or L2 native tokens such as ETH for Ethereum, SOL for Solana, or BNB for BNB Chain. If your project is not a chain, this is not your category.
• Staking for network security. Validators lock the token as collateral for honest behavior on a proof-of-stake chain. Same scope, only relevant if your project runs its own consensus.
• Staking for access or privileges. Locking the token unlocks features. BNB at fee-discount tiers, HYPE for permissioned actions like launching new perpetual markets on Hyperliquid, veCRV for boosted gauge rewards. The lock is what creates the holding demand. See our staking primer for the mechanics.
• Collateral. Used as backing for synthetic assets, loans, or market-making. CRV inside Curve's gauge system, MKR before the Sky rebrand, AAVE in safety-module style staking.
• Governance. Voting rights on protocol parameters. The category most tokens lean on, often the only one they have. Covered separately in our governance primer.
• Work token. Holding or staking the native token is required to perform revenue-generating work. Livepeer, Augur historically, most DePIN networks. Most underused category outside infrastructure.

Most "utility tokens" have exactly one of these functions. A few have two. Projects that claim all six are usually faking all six. Founders designing utility should pick one or two and design them deeply, not stack five thin claims to look complete. If you cannot point to which of the six your token does, and how a holder accesses that function, the token does not have a utility argument, only a marketing one.

The "could the protocol survive without it?" test

There is a popular test in tokenomics circles: if the token disappeared overnight, would the protocol still work? The framing says yes means no real utility, no means real utility. I disagree with the framing, sharply.

The standard test conflates two different questions. Whether a token is mandatory for protocol function, and whether the token captures value created by the protocol. AAVE the protocol could run on stablecoins and other governance primitives, the AAVE token is not load-bearing for lending operations. By the standard test, AAVE has no utility. In practice, the AAVE token captures value through the safety module, governance authority over risk parameters, and the protocol's revenue plans. The token adds value even though it could be removed.

The right question is not "could you remove the token", but "what does holding the token uniquely let you do, and does that activity grow with the protocol?" If holding gates a paid action, the token has utility. If holding has no required role anywhere in the system, the token is a souvenir, no matter how much branding sits on it. L1 native tokens are the structural exception, gas and security create a substitution-resistant requirement that other tokens cannot replicate cheaply.

For everyone else, design utility as additive, not mandatory. A token that adds value when used right and does not break the system when used wrong is a more robust design than one whose collapse takes the protocol with it.

Utility versus value capture, and the velocity problem

A token can have real utility and accrue almost no value to holders. This is the trap most teams fall into, and it is the single most important distinction to understand before designing a token economy. Read more in our value accrual primer.

Uniswap is the canonical case. UNI launched in 2020 with governance utility, voting on protocol parameters and fee splits. For five years, the protocol generated billions in trading fees, all of which flowed to liquidity providers, none to UNI holders. UNI's price was effectively uncorrelated with Uniswap's dominance. The token had a function, governance, and the function had a use, voting, but holding demand did not grow as Uniswap grew because there was nothing to hold for.

This changed in late 2025. The UNIfication proposal, jointly introduced by Uniswap Labs and the Uniswap Foundation in November and approved on-chain on December 25 with near-unanimous support (fewer than 740 votes against out of 125 million cast), activated the long-debated fee switch. Roughly one-sixth to one-quarter of swap fees are now redirected into a contract called the token jar, and UNI holders can burn their tokens through a separate contract called fire pit to withdraw an equivalent amount of crypto from the jar. A retroactive 100 million UNI burn from the treasury was approved alongside, an estimate of what would have been burned had the mechanism been live since launch. Five years late, UNI has a value capture mechanism that ties holding demand to protocol usage.

The lesson is that utility and value capture are different design questions. Founders should distinguish between (a) what the token is used for, and (b) what causes holding demand to increase as the protocol grows. A token with utility and no value capture is a commodity, holders extract nothing from protocol growth no matter how big the protocol gets.

The mechanism that ties the two is velocity. If users acquire the token, immediately use it, and immediately sell the remainder, holding demand stays weak no matter how much the protocol grows. Pure payment tokens have the highest velocity and the weakest value capture, which is the underlying reason payment is not utility. Staking, collateral, access gates, and time locks all reduce velocity because they require the token to sit out of circulation during its useful life. The design question for any utility argument is: what keeps the token out of circulation? If the answer is "nothing", value capture will be weak however large the protocol grows.

Work tokens, the most underused pattern

Work tokens are the design pattern most underused outside DePIN. The mechanism: you must hold and stake the native token to earn the right to perform revenue-generating work on the protocol. Livepeer is the canonical clean example, orchestrators stake LPT to be eligible for transcoding work, and the more LPT staked the more work can be routed. Augur historically used a similar pattern, REP holders had to stake to report on prediction-market outcomes.

The economic loop is direct. Protocol revenue grows, demand for work slots grows, demand to hold the token grows, token price rises, each work slot becomes more valuable to protect, security improves, the protocol can support more workload. Each step has a real mechanism behind it, not a theoretical one. The token is load-bearing because the work cannot happen without it, and the work is what users pay for.

DePIN networks are essentially work tokens with physical-work verification. You stake or hold the native token to be eligible to provide hardware, bandwidth, storage, or some other physical resource, and you earn for verified work delivered. Filecoin, Helium, Hivemapper, Geodnet are all variants of this pattern. The category has worked partly because the work is real, the verification is on-chain or at least cryptographically attestable, and the tokens have a direct economic claim on what users pay for.

Outside DePIN, the model is rare and worth more attention. Any protocol where participants do something for payment is a candidate: oracle networks, prediction markets, reputation systems, content moderation, decentralized compute. The reason teams default to governance tokens instead is that governance tokens are easier to launch, you do not need to define the work, build the verification, or convince supply-side participants to lock capital. The harder design produces stronger value capture.

Governance-only, dual-token, and points: three patterns that often fail

Three common designs deserve flagging because they fail or get misused in predictable ways. Why? Because each one papers over a different gap between utility and value capture, and the gap shows up at TGE or shortly after. If you are working through whether your token's utility argument actually clears the value-capture bar, that is the kind of design problem we work through with founders during our tokenomics consulting engagements.

Governance-only tokens were the dominant launch pattern from 2020 to 2023. The pitch: governance rights are valuable because the protocol is valuable, holders capture upside through influence over future direction. The reality: governance rights without a revenue claim or fee capture price approximately as the option value of future fee capture, which markets have repeatedly priced near zero. UNIfication is, in part, a belated acknowledgement that pure governance was not enough, and Uniswap had the strongest possible case for "governance is enough", with $4 trillion in cumulative volume and the dominant DEX position. If pure governance does not work for Uniswap, it does not work for a smaller protocol either. If your only utility argument is governance, you are selling an option on future value capture, market it honestly as that or design real utility in.

Dual-token architectures separate speculation from operation, and they are common across consumer-facing protocols. Axie Infinity used AXS (governance) plus SLP (gameplay), Helium uses HNT (value capture) plus Data Credits (USD-pegged payment), STEPN runs GMT (governance) plus GST (gameplay), Filecoin pairs FIL (network token) with storage collateral. The pattern is one token captures value and accrues ownership, a second token handles in-ecosystem transactions at stable or near-stable prices, insulating users from the governance token's volatility. The failure mode is inflation in the operational token: SLP hyperinflated and Axie's gameplay flywheel broke under the weight of unbounded earn-side issuance. Dual-token only works if the operational token can credibly be held stable, and most teams do not stress-test that assumption hard enough before committing.

Points programs are utility proxies, useful and dangerous in different ways. Points let users earn something redeemable for tokens later. They function as utility bootstrapping, users do what the protocol wants in exchange for a future claim. The advantages are real: no token dilution visible pre-TGE, less direct securities exposure, full team control over the redemption ratio. The disadvantages are also real: users get a non-transferable claim with no price discovery, protocols face a "points crash" at TGE when the redemption ratio disappoints, and the whole mechanism concentrates airdrop farmers who exit at TGE. Blast, Eigenlayer, and Ethena all ran versions, with mixed retention outcomes after redemption. Points are a tool for early liquidity, not a substitute for designing utility, and the tradeoffs are worth understanding before launching one.

Designing utility for the right audience and jurisdiction

Two design constraints get under-counted. The first is who the user actually is. The second is how regulators classify the token.

Most tokenomics design implicitly targets crypto-native users, wallet-holding, willing to stake, comfortable with DeFi UX. But many protocols are trying to serve a much broader user base: Helium Mobile subscribers, Filecoin enterprise storage clients, Hyperliquid retail traders. Those users do not want to manage token utility, they want the service. The token's utility, in those cases, needs to be invisible to them, handled in the background, paid in credits or fiat, with the token serving the protocol's economic layer for holders, validators, LPs, and governance. Conflating the user-facing UX with the holder-facing utility produces UX disasters and tokens that nobody wants to hold for either reason.

The second constraint is jurisdiction. Under MiCAR, the EU's Markets in Crypto-Assets Regulation, fully in force since December 30, 2024, a "utility token" is defined narrowly as a crypto-asset that is only intended to provide access to a good or a service supplied by its issuer. Anything broader, especially anything that promises revenue share, profit participation, or acts primarily as a means of exchange, falls into a different category: ART (asset-referenced token), EMT (e-money token), or potentially a financial instrument under MiFID II. Founders marketing a token as a "utility token" in EU jurisdictions need to check whether it actually meets the MiCAR definition, or whether they are operating under a different category without a corresponding whitepaper or licensing path. The label is a regulatory determination, not a marketing one.

More from the 101 series

This article is part of our tokenomics 101 series. A few more pieces on adjacent design questions worth working through:

• Token Payment 101, on why payment is its own design problem with different value capture properties.
• Token Burning 101, on burn mechanisms and where they actually capture value (relevant to Uniswap's token jar).
• Token Emissions 101, on how new issuance shapes token demand for work-token and dual-token designs.
• Tokenomics Design 101, the broader design framework these primers fit into.

Hristo Piyankov

Lead token economist

Hristo is one of the best-known tokenomics designers in the industry. He is a top Web3 LinkedIn voice and a mentor in several high-profile accelerators such as Brinc and HyperNest. Hristo teaches a university masters degree in Cryptoeconomics and Decentralised Finance (DeFi). Having worked on over 300 tokenomics projects, he knows the ins and outs of token economies, what works and what does not.

Prior to working in crypto, Hristo was an Analytics Director and a Data Scientist for 12+ years in TradFi.