A utility token is a token spent inside a product to pay a fee, buy a service or unlock a function. Structurally it is the opposite of a security token: anyone can hold it, transfers carry no eligibility check, and it usually runs on a plain fungible interface with no restriction logic at all. That openness is the design, and it is also what makes the utility claim testable rather than rhetorical.
A utility token is only a utility token if something consumes it in the ordinary course of using the product. If you cannot name the buyer, the day, the amount and the function that breaks without it, you have a distribution mechanism with a utility label on it.
Scroll to see the full diagram
The instrument: something you spend
The distinguishing property is consumption. A utility token is presented to a product in exchange for something the product does: compute, storage, bandwidth, a listing, a match, an inference call, a game action. The holder gives up the token and receives the service, which is a fundamentally different relationship from holding a claim on somebody else's future work.
That relationship sets the demand curve. Demand for a genuine utility token tracks usage of the product, which means it is bounded by how much of the service people actually buy. It is not an unlimited demand story and pretending otherwise is where most utility models fall over. If the service is worth $2 million a year, the token's usage demand is worth roughly $2 million a year divided by how many times each token gets reused.
This is also where the firm's position sits. Tokenomics enhances value creation, it does not substitute for it. A utility token attached to a product nobody pays for is a token with no sink, and no mechanism fixes that.
The rail is a plain fungible interface, and that is the structural tell
Most utility tokens implement EIP-20 and nothing else. The standard requires six functions and two events and marks name, symbol and decimals as optional; it contains no concept of an eligible holder, a jurisdiction, or a transfer that may be refused.1 Any address can receive, any address can send, and the contract has no opinion about either.
That absence is the technical difference between a utility token and a permissioned instrument, and it is visible in a contract read in under a minute. A token that checks an identity registry before every transfer is not making a utility claim, whatever the marketing says. A token that checks nothing has at least built the thing it says it built.
NIST's overview of token design frames this neutrally: what a token can and cannot do is a design and management choice rather than a property of the underlying technology.2 Open transferability is something you chose, and it is a choice with consequences on both sides.
Consumables are usually ERC-1155, not ERC-20
A design detail that gets missed. Plenty of things called utility tokens are not a single fungible unit at all: game inventories, event passes, credit bundles and tiered access rights are collections of distinct item types with many copies each.
ERC-1155 specifies an interface for contracts managing multiple token types in one deployment, in any combination of fungible, non-fungible and semi-fungible, with batch balance reads and batch transfers.3 For an inventory of forty item types with thousands of copies, that is one contract and one call instead of forty deployments and thousands of individual transfers.
Choosing ERC-20 for something that is structurally an inventory produces a token that has to be exchanged for the real items through a second mechanism, which adds a step, a fee and a place for the design to leak. Match the standard to the shape of what is actually consumed.
Where the label and the structure came apart
The historical record on this is specific rather than general. On 11 December 2017 the SEC issued a settled order against Munchee Inc., halting a token sale that had been marketed with utility framing before the product's token functionality existed.4 The order is a dated fact and it is cited here as one.
The reasoning behind it, the four-prong investment-contract analysis and how it applies to any particular sale, belongs on our Howey test and security versus commodity classification pages, and the answer for a specific token is a matter for counsel on that token's facts. This page will not relitigate it.
What sits in this lane is the design lesson, which is narrower and more useful: a utility claim made before the utility exists is a claim about the future, and a claim about the future is the thing buyers price. Shipping the function before the sale changes the structure of the transaction, not just its description.
The usage proof we ask for
Before we sign off on a utility design, we ask for one paragraph that answers five questions with specifics. Who spends the token. On which day, in the ordinary course of using the product. How much, denominated. In which token, and whether the user could pay in something else instead. And what function stops working if the token is removed from the design entirely.
That last question is the one that fails most often. If the product works identically with a credit card and a database row, the token is a payment rail choice rather than a mechanism, and it should be evaluated as one. There is nothing wrong with that answer; there is a lot wrong with not knowing it.
Across the projects we have advised, the designs that hold up are the ones where the answer to the fifth question is concrete and slightly boring. A permissioned resource that has to be metered. A spam cost that has to be non-zero. A settlement asset between parties who do not share a bank.
Before you call it a utility token
Four things. The usage proof paragraph, written and defended. The sink inventory: every mechanism that removes tokens from circulation in normal operation, with a size estimate attached to each. The distribution plan, including what buyers are told to expect, because that is the material that gets read back later. And the standard, matched to whether you are issuing a fungible unit or an inventory.
Two of those are economic and two are legal-adjacent, and they interact. A design with weak sinks tends to lean harder on price narrative in its marketing, which is exactly the material that makes the classification question harder. Fixing the sink is usually cheaper than managing the consequence.
This page is design reference, not legal advice, and it does not recommend buying, selling or holding anything. Whether a particular token is a security where you are selling it depends on the facts of that sale, and that is a lawyer's call. The token is infrastructure for a product. If the product is not creating value, the label on the token is the least of the problems.
Common questions
What is a utility token?
A utility token is a token spent inside a product to pay a fee, buy a service or unlock a function, so demand for it tracks usage of that product. Structurally it is openly transferable: it normally runs on a plain fungible interface such as EIP-20, which has no concept of an eligible holder and never refuses a transfer.1 Anyone can hold it and no eligibility check runs.
How do you tell a real utility token from a label?
Ask five questions and require specifics. Who spends it, on what day in normal product use, how much, in which token, and what function stops working if the token is removed from the design. The fifth question is the one that fails most often. If the product behaves identically with a credit card and a database row, the token is a payment rail choice rather than a mechanism.
Can a utility token still be treated as a security?
Yes, because the analysis attaches to the transaction and to what buyers were told, not to the name. In one dated example, the SEC issued a settled order in December 2017 halting the Munchee token sale, which had been marketed with utility framing before the token functionality existed.4 Whether any particular token is a security where it was sold turns on the facts of that sale and is a matter for counsel.
Which token standard should a utility token use?
It depends on whether you are issuing one fungible unit or an inventory. A single interchangeable unit of account fits EIP-20, which requires six functions and two events and adds no restriction logic.1 Game items, passes and tiered credits are usually many item types with many copies each, which fits ERC-1155, where one contract manages fungible, non-fungible and semi-fungible balances with batch transfers.3
See Tokenomics Design Services for how this applies in practice.
Sources
- EIP-20: Token Standard
Ethereum Improvement Proposals, 2015
Six required functions and two events, with name, symbol and decimals optional. Contains no concept of an eligible holder, a jurisdiction or a refusable transfer. - NISTIR 8301: Blockchain Networks, Token Design and Management Overview
National Institute of Standards and Technology, 2021
Frames token behaviour and custody arrangements as design and management choices rather than inherent properties of the technology. - EIP-1155: Multi Token Standard
Ethereum Improvement Proposals, 2018
One contract managing multiple token types, fungible, non-fungible and semi-fungible, with batch balance reads and batch transfers. The natural fit for consumable inventories. - In the Matter of Munchee Inc., Securities Act Release No. 10445
U.S. Securities and Exchange Commission, 2017
Settled order of 11 December 2017 halting a token sale marketed with utility framing. Cited here as a dated record; the classification analysis is treated on the Howey test page.
Last reviewed 2026-08
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.
100+ projects advised. Complete tokenomics in 4 to 6 weeks.