Utility test

Four slots, four different kinds of vagueness

Who demands an identified party: validators, hardware operators, enterprise buyers, a named class of user you could in principle count. What demands a specific action: staking a minimum balance, paying a per-call fee, posting a bond, buying a usage credit. Paying what demands a token-denominated price or rate. On which day demands that the mechanism is live, or has a committed date, rather than a roadmap position.

Each blank fails differently, which is the reason to keep them separate. A missing who means you have not identified your buyer. A missing what means you have a category rather than a mechanism. A missing price means the team retains discretion over the economics, which makes the utility unforecastable. A missing date means it does not exist. Holders will access premium features fails all four at once, which is why that sentence and its variants show up in so many decks.

Run against your own whitepaper this is uncomfortable in about ninety seconds, and that discomfort is the deliverable.

Who: use a taxonomy, not an adjective

The who slot fails most often through generosity. Users, holders, the community and participants are not parties. They are audiences. A party is a role in the system with an obligation attached, and if you cannot describe what that role does when it is not touching your token, you have not found it yet.

There is more formal vocabulary available than most teams use. The NIST technical report on blockchain token design and management sets out a government-authored taxonomy of the functional roles a token can serve and how those roles are managed, which is a neutral reference rather than a vendor framework.¹ Academic token-classification work out of the European Blockchain Center at the IT University of Copenhagen does something similar for token systems and their functional roles.² Neither will design your mechanism. Both will stop you inventing a category that already has a name and a known failure mode.

Paying what: the slot that makes the model falsifiable

A price expressed in tokens is a commitment. A price expressed in dollars, with the token amount floating to match, is a different mechanism entirely, and one where token demand is inversely related to token price. Both are legitimate designs. Only one of them produces demand that scales with adoption, and teams routinely write the second while modelling the first.

The slot also exposes discretion. If the fee is set by the team, adjustable at will, and not bounded by governance, then the utility is whatever the team decides it is next quarter. That is not a mechanism a buyer can underwrite, and in a diligence process it reads as exactly what it is. Where discretion is genuinely needed, bound it: a range, a governance process, a rate-change cadence. Bounded discretion is defensible. Unbounded discretion is a promise.

On which day: live, dated, or absent

Here is the test run against a concrete mechanism, and to be clear this is a constructed illustration rather than a specific protocol: a compute network requires every provider to stake 10,000 tokens before its node is eligible for job routing, enforced at registration, live on mainnet. Who is compute providers. What is staking 10,000 tokens. Paying what is 10,000 tokens at whatever they cost that day. On which day is at registration, now. Four slots filled, all four countable, and the demand figure follows from the provider count.

Now the same mechanism at the more common stage of maturity: providers will stake tokens to participate in the network. Who is providers, which is passable. What is stake, with no amount. Paying what is unanswered. On which day is unanswered. That sentence is not a smaller version of the first one. It is a different kind of object, and treating it as a mechanism in a financial model is how models end up with demand curves that were never grounded in anything.

Sheng's diligence framing is the useful companion here, since it asks whether the project would still function if the token were removed or replaced.³ A mechanism that passes the utility test is at least specific enough that you can answer his question honestly.

What passing does not prove

A mechanism can be perfectly specific and economically trivial. A 5-token fee on an action nobody performs fills all four slots and generates nothing. Passing the utility test means the claim is real and checkable, not that it is large. Size it separately: parties multiplied by obligation multiplied by frequency, which is arithmetic you can only do once the four slots are filled.

Passing also does not prove necessity. Those are different tests, deliberately. A design can have a live, specific, well-priced token mechanism that a stablecoin would have handled better, in which case you have a real utility and a token that did not need to exist. Run necessity first, utility second, and do not let a strong result on one paper over a failure on the other.

Across the 100+ projects the firm has worked on, the more common pattern is the reverse of what teams expect. The token usually turns out to be necessary in one narrow place and decorative in the other four places the deck claims for it. The utility test finds which is which.

Regulators run a version of this, from the other direction

The reason specificity matters beyond internal hygiene is that the securities analysis turns partly on whether an asset is bought for genuine consumptive use or in reliance on the efforts of a promoter. The 2019 SEC staff framework for digital assets set that analysis out in detail, and the Harvard Law Review discussion of it is the accessible route into what it actually asked.⁴ The framework was published as staff guidance and its status as such has since been withdrawn, so it describes how the analysis has been framed rather than a current agency position.

In our view, and this is opinion rather than law, a token whose utility cannot be stated with a party, a price and a date is a token whose holders are relying on something other than consumptive use. That is a fact-specific and jurisdiction-specific question that belongs with your counsel. What we can say from the design side is that the documentation you produce to pass a utility test is the same documentation your lawyers will ask for, so writing it once early is strictly cheaper. This page is design reference material, not legal advice, and nothing here is a recommendation about any asset.