The utility test is a concrete check on whether a token's utility is real: name who is doing what, paying what, on which day. If the answer cannot be specified, the utility is not real yet, no matter how confidently the whitepaper describes it. Specificity is the minimum bar.
If a team cannot pass the utility test for their own token, they have a product specification problem, not just a token design problem.
How it works
The test has four parts. Who demands an identified user class: validators, content creators, enterprise buyers, retail users. What demands a specific action: staking a minimum balance, paying a per-transaction fee, buying a usage credit.
Paying what demands a token-denominated price or rate, not a dollar figure left to the team's discretion. On which day demands that the mechanism is live or has a defined launch date, not a roadmap item.
Common mistake
Whitepapers fail this routinely because pre-launch utility language is deliberately abstract. Holders will access premium features fails who, what, paying what, and when all at once: which holders, which features, at what token cost, on what date? The abstraction is often not a drafting choice but a sign of genuine uncertainty about whether the mechanism will ship.
Example
Run the test on a live mechanism. A decentralized compute network requires each provider to stake 10,000 tokens before its node is eligible for job routing. The who is compute providers, the what is staking 10,000 tokens, the paying what is 10,000 tokens at market price, the when is at node registration, live on mainnet. That passes. The mechanism is specific, verifiable, and operational, which is the whole point of the test.
See Tokenomics Audit for how this applies in practice.
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.
80+ projects advised. Complete tokenomics in 4 to 6 weeks.