Token-necessity test

This is our vocabulary, and the questions inside it are not

Nobody should claim a pedigree they do not have, so: token-necessity test is the firm's name for a diagnostic, not a doctrine with a citable origin. What is published, and what we built it out of, is a set of separate arguments made by named people about when a token has a job. The clearest single articulation is Tony Sheng's diligence question, which asks whether the project would still function if the token were removed or replaced, explicitly framed as a diligence heuristic rather than a theorem.¹

Naming it turns four scattered arguments into something a team can fail in a specific place. Failing question two is a different problem, with a different fix, from failing question three. A verdict that the token feels unnecessary helps nobody. A verdict that the design fails indispensability and passes the rest tells you what to go and build.

Question one: does the token coordinate parties you do not control?

A token earns its place when it aligns actors who are not on your payroll and who would not otherwise cooperate: independent validators, hardware operators, liquidity providers, third-party developers, competing marketplaces. The mechanism has to do work that a contract or an API key could not.

There is real economic support for this being the strongest case. The formal model in Goldstein, Gupta and Sverchkov's work on utility tokens argues that a token can serve as a commitment device that limits rent-seeking by a two-sided platform, because the issuer gives up the ability to extract from participants later.² That is a coordination function with teeth, and it is fundamentally about what the issuer can no longer do.

A no here means you are running a single-party system with a token attached. Not automatically fatal, but it moves the burden entirely onto the next three questions, and it removes the argument most likely to survive scrutiny from an economist or a regulator.

Question two: would the product break without it?

Delete the token from the architecture diagram and describe what stops working. Not what gets less exciting. What stops. If the answer is that the rewards program ends, you have deleted a marketing budget, not a mechanism. If the answer is that operators can no longer be bonded, that unbonded operators cannot be penalised, and that the network therefore has no way to price bad behaviour, the token was structural.

Failing this question produces the most common architecture we see: a working product with a token layered on top as an overlay. Every user path has a token-free equivalent, the team knows it, and the model quietly depends on nobody noticing. Users notice. They route around the token the moment doing so is cheaper, and the overlay becomes a rounding error in the P and L with a market cap attached.

Question three: could a stablecoin do this job?

This is the question that fails most often, and it is the one teams most resent. If the token's role is to be paid, spent, or priced against, ask why a dollar-denominated unit would not work better for everyone involved. Your users budget in dollars. Your enterprise customers cannot put a volatile unit in a procurement contract without a hedging conversation they did not want.

Buterin's analysis of medium-of-exchange token valuations is the useful reference here, because it shows why the answer is structural rather than aesthetic. Value in that framework depends heavily on holding time, so a token that people acquire and immediately spend has weak price support by construction.³ A pure payment token that nobody has a reason to hold is competing with a stablecoin while carrying volatility a stablecoin does not.

Passing this question requires the token to unlock something a stablecoin structurally cannot: a claim on protocol governance, a security bond that must be slashable in the unit the protocol controls, an access right the protocol can price in its own terms. Those are real answers. Cheaper fees when paying in the native token is a discount, and a discount is a subsidy with a different name.

Question four: does real activity force acquisition?

The final question is the hardest to fake and the easiest to check later. When usage of the product goes up, does anyone have to go to market and buy the token, or does usage rise while token demand stays flat? This is the demand-sink question, and the necessity test only asks it in binary: yes with a named mechanism, or no.

A no here has a specific and predictable consequence. Price tracks the emission schedule downward more or less regardless of how the protocol performs, because the only recurring flow is supply. Teams then attempt to fix it with a burn, which changes the supply side of an equation whose demand side was never built. We have watched that sequence enough times across 100+ projects to treat a question-four failure as the most expensive of the four to defer.

What a failing test is actually worth

There is a regulatory shadow over all of this that is worth naming without overstating. The SEC's 2019 staff framework for analysing digital assets asked, among many other things, whether purchasers are relying on the managerial or entrepreneurial efforts of others rather than acquiring an asset for genuine consumptive use.⁴ That document was published as staff guidance and its status as such was subsequently withdrawn, so read it as a description of how the analysis was framed rather than as a current agency position or a test you can pass.

Our view, offered as opinion rather than as law, is that the overlap is not a coincidence. A token that fails necessity tends to be a token whose holders are, in substance, relying on the team to make it worth something. That is an uncomfortable place to be standing, and whether any specific token is a security is fact-specific, jurisdiction-specific and a question for your counsel. This page is design reference material. It is not legal advice and it is not a recommendation about any asset.

The practical worth of a failing test is that it is cheap. A necessity test costs a few days at the start of a project. The alternative is a raise, a launch, a listing and a two-year vesting schedule built on a mechanism that never had a job, and the correct answer arriving anyway, just later and in public.