Token utility

The removal test, in the words of the analyst who wrote it

Tony Sheng's diligence framework for utility tokens splits into two questions: is the project strong, and is the token designed well. The second one opens with whether the token is even needed, because if it is not, someone will clone the project without it and users will prefer the clone for the lower friction and lower price.³

His starting point is worth quoting exactly. If someone made a clone of this project, took out the token and replaced it with its parent token such as Ethereum, would it function just as well? If the answer is yes, the token is not needed.³ He frames it as a diligence question rather than a theorem, which is the right level of confidence to hold it at, and it still ends most arguments about an unnecessary token in one question.

Founders fail it in a specific way. The token is required by the contract but not by the user, because the front end buys and sells it inside one transaction. Anything a router handles in a single click is not a reason to hold.

Five token models, and what each does to the price relationship

Sheng maps token models against the correlation between price and utility as utility approaches its maximum. A token used only as a transaction fee in a proprietary payment system gets a negative reading, trending toward zero. A work token, staked for the permission to do work in the network, gets a positive one. A burn or mint model reads positive if it produces a net decrease in supply and negative if it produces a net increase. A discount token reads positive, with the caveat that you are better off using the discount than speculating on it. Governance reads positive.³

Two things about that table matter more than the ratings. First, these are one named analyst's assessments of a design class, not measured results, and he says so. Second, most projects run several models at once, so the question is which model dominates as usage grows, and he is explicit that he does not know how to predict that.³

We use it as a sorting device, not a scoring device. If your token's only model is the first row, you are designing against a headwind your own users will find before your investors do.

What the finance literature can actually show

The strongest formal result available is Goldstein, Gupta and Sverchkov, forthcoming in the Journal of Finance. They model two-sided platforms where buyers and sellers meet to exchange services, with tokens as the sole medium of exchange on the platform and tradable in a secondary market. Their result is that tokenising a platform commits the operating firm to give up the monopolistic rents that come with controlling it, which produces competitive prices in the long run while preserving the efficiency gains from network effects.¹

Note what the token is doing there. It is not a rewards programme or a fundraising instrument. It is a commitment device: the reason it creates value is that it takes power away from the people who issued it. That is a genuine economic function and it is a high bar.

The authors are careful about how far it travels. They state that a few features are critical for utility tokens to serve this purpose, that those features have not been consistently adopted in practice, and that their analysis is normative rather than positive.¹ Read plainly: the paper shows what utility could do, not what most live tokens do.

Even the standards body says the label is used inconsistently

NIST's overview of blockchain token design and management is a useful neutral reference precisely because it has nothing to sell. It builds a conceptual framework around five views of a token system covering the token, the wallet, the transaction, the user interface and the protocol.²

On the word itself, it is blunt. Fungible tokens native to a protocol and used to decentralise its governance are, in its phrasing, largely but inconsistently referred to as platform or utility tokens.² A US government technical report noting that the industry applies the term inconsistently is about as clear a signal as you will get that utility is a description of a design choice, not a category anything falls into automatically.

Utility is not a regulatory category

Teams reach for the word utility because they believe it does legal work. It does not do the work they think. The SEC's 2019 staff framework for investment contract analysis of digital assets asks, among other things, whether purchasers are relying on the managerial or entrepreneurial efforts of others, as against acquiring the asset for genuine consumptive use.⁴ Consumptive use is one input into a fact-specific analysis. It is not a label a project applies to itself.

That document was issued as staff guidance and its standing has since been revisited, so treat it as an articulation of how the analysis was framed rather than as current binding policy. In our view the design lesson survives either way. A token people buy because a team promised to make it valuable behaves differently from one people buy because they need it today, and the difference shows up in purchase behaviour rather than in the deck.

Whether any particular token is a security is fact-specific and jurisdiction-specific and belongs to your counsel. This page is design reference. It is not legal advice and it is not a recommendation to buy, sell or hold anything.

What we ask a team to write down

Three lines, before any mechanism work starts. Name the action that cannot be completed without the token. Name who takes it and how often, in units. Name what they would do instead if the token vanished tomorrow. If the third line is a shrug, there is no utility to design around, and a staking contract on top will not create one.

Then check the funding. Utility that exists because the protocol is paying people to exercise it is a marketing budget with a smart contract attached, and it ends on the schedule the emissions end on. Utility that exists because the product is worth using survives the schedule.

The token is infrastructure for the business underneath it. When that business genuinely routes something through the token, utility is easy to state in a sentence. When it does not, no amount of mechanism will produce a sentence worth reading.