When Not To Use a Token at All

Most token decks we review shouldn’t have a token at all.

Founders slap on a coin because “that’s what web3 does,” then spend the next two years wrestling with regulators, baffling users, and detonating their own cap table. The punchline: in the majority of these cases, a vanilla app with a database and Stripe would have shipped faster, scaled cleaner, and been worth more.

This piece is a straight answer to an uncomfortable question: when does a token actually create leverage – and when is it just a shiny tax on your legal bill and user experience?

If you’re at idea stage and everyone in the room is chanting “where’s the token?”, this is the framework you can drop on the table and say: here’s why we’re doing it – or why we’re not.

A token has three, and only three, real jobs.

First: meter scarce onchain resources — blockspace, bandwidth, storage, liquidity. ETH for gas, LINK for oracle queries, GMX’s escrowed token for revenue share — these are all doing the same thing: pricing access to a bottleneck. If your product doesn’t surface a genuine onchain constraint, you almost certainly don’t need a metering token.

Second: coordinate risk and upside for groups that don’t fit neatly into a cap table — LPs in a DEX, node operators in a network, creators and curators in a marketplace. UNI is a good example here. Governance cosplay aside, it’s at least tied to a real coordination question: who directs the protocol that thousands of LPs rely on?

Third: enable permissionless composability. Other protocols can snap your token in as collateral, governance, or routing infrastructure without talking to you first. That’s why stablecoins and LSTs sit at the base of DeFi: they’re clean, legible primitives, so the rest of the stack can standardize around them.

If your token doesn’t clearly anchor to one of these three jobs, you’re not designing utility — you’re manufacturing busywork.

Founders are usually strong storytellers—which is exactly how they end up over-justifying tokens.

Fake job #1: “engagement.” You don’t need a transferable, speculative asset to get people to open your app. Points, badges, tiers, and leaderboards have been shaping behavior for decades without tripping securities rules. A token on top doesn’t manufacture retention; it just pulls in mercenary farmers who disappear the moment emissions slow down.

Fake job #2: “community ownership” as a mood. Real ownership is concrete: rights to cash flows, governance/control, or privileged access. If your token can’t credibly deliver at least one of those, you’re not creating owners—you’re selling lottery tickets with branding. We’ve already watched this movie in creator tokens that spiked at launch, then drifted down 95% while the actual fan community kept operating mostly off-chain.

Fake job #3: “fundraising wrapper.” Yes, tokens can be a capital-raising tool. But if the token’s only purpose is “something we can sell,” two things happen: regulators eventually take interest, and serious investors haircut your valuation relative to a straightforward equity round.

Here’s the no-bullshit decision tree we walk through with founders.

Start from the core transaction: what is the user actually doing? If the answer is “reading content”, “tracking workouts”, or “booking appointments”, you’re in web2 land. No token. If the answer is “providing liquidity”, “posting collateral”, or “running infrastructure”, then you might have something.

Next: is there a real onchain bottleneck or a shared risk pool? If not, stop. You don’t need a fungible token. You can still use wallets, signatures, NFTs, and other primitives for access and identity. If yes, ask whether a single existing asset (USDC, ETH, an LST) can cover the need. If it can, use that – composability is an advantage, not a limitation.

Only if you get to a hard “no” on existing assets should you even consider designing your own token. And even then, default to non-transferable or very tightly scoped usage until you have product–market fit. The earlier you lean into full casino dynamics, the harder it becomes to unwind when regulators, counterparties, or users push back.

Once you strip away the hype, most early-stage teams don’t need “a token” — they need solid software and clean accounting.

Points systems already cover most of what founders are trying to do with tokens: track contribution, reward behavior, and run controlled experiments. They’re off‑chain, reversible, cheap to iterate on, and don’t require a legal memo every time you change the rules. Binance ran with off‑chain “points” and tiered VIP programs for years before putting anything on-chain in a formal way.

Plain SaaS wired into wallets is another underused path. You can let users authenticate with wallets, verify NFT ownership, or gate features on top of onchain data — all without issuing a token. That’s how many serious fintechs are integrating crypto rails today: they move USDC or other stablecoins behind the scenes, while the end user never has to manage a new speculative asset.

And the basics still work: equity and revenue-share. If you want to align a tight group of core users or strategic partners, a cap table plus a contract is usually more enforceable — and far more legible to future investors — than a rushed governance token launch.

Saying “no token” is often a harder political decision than shipping a poorly designed one.

Investors want upside, advisors want to signal they’re “web3-native”, and early users want airdrops. Your job as a founder is to separate narrative candy from product reality. The cleanest way is to anchor everyone on jobs-to-be-done: here’s what the product does, here’s how value actually flows, and here’s why a token would add drag instead of leverage at this stage.

You can still offer an upside story without a token on day one. Equity, future revenue share, or even a concrete “if we ever issue a token, here’s the framework we’ll use” memo can defuse hype without locking you into a bad structure. The important part is being explicit: we’re not anti-token, we’re anti-toy-token. When the product genuinely needs one of the three real token jobs, we’ll design it from a position of strength, not FOMO.

If you take one thing away, make it this: tokens are leverage, not ornament. They should either meter a real onchain resource, coordinate a messy risk pool, or plug users into a wider DeFi/creator stack. Anything outside those jobs is just a liability with a ticker.

At idea stage, your edge is the freedom to say “not yet” while everyone else sprints to list something. Use that window. Lay down the boring rails, validate the core transaction, and preserve your degrees of freedom. When a token truly makes the flywheel spin faster, it’ll be obvious – and you’ll be in a position to design it on your terms.

Run the hard test: what actually breaks if you rip the token out? If the honest answer is “not much,” that’s your signal. Close the tokenomics deck, ship the product people demonstrably want, and let the token follow the value – not the other way around.