Most failed tokens were not broken at the math layer. They were broken at the moment someone decided to launch a token before they could articulate, in one sentence, what the product does. The allocations, the emission curve, the vesting — all of that is downstream. If the product is not a real product, no mechanism will save the token. If the product is real, the mechanism almost designs itself. This is what we mean by product-led tokenomics: treating the token as a consequence of the product rather than an input to it.
This article describes the framework we use to get from a product to its tokenomics in a defensible order. It is aimed at founders, CPOs, and token designers who are past the “do we need a token” question (covered in when you don’t need a token) and are now looking at the blank canvas of what the token should actually do.
The Failure Mode: Token-First Design
The dominant failure mode in this industry is not bad math. It is sequencing. A team decides on a token — usually under fundraising pressure — and then backfills utility. The product gets contorted to justify the token: forced staking to “reduce circulating supply,” governance over parameters nobody actually disputes, discounts that would have been cheaper as a fiat subsidy. The token extracts value from users instead of capturing value that already flows through the product.
The cleanest diagnostic: ask a founder “if we deleted the token tomorrow, what would break in the product?”. If the honest answer is “nothing critical,” the token was never part of the product. It was a financing instrument wearing a product costume.
The Four Layers
Product-led tokenomics moves through four layers, in order, and each layer constrains the next. Skipping a layer means the next one has no ground to stand on.
Layer 1 — Jobs-to-be-done. What does a user actually hire this product for? Not “access to Web3” or “decentralization” — a concrete job: move USD from one country to another cheaper, earn yield on idle BTC, launch a memecoin without writing Solidity, settle a derivative without counterparty risk. If the JTBD cannot be written on a napkin, the token cannot be written either.
Layer 2 — Value proposition. Given the JTBD, what is the product promising? Cheaper, faster, more transparent, permissionless, composable. This layer filters which parts of the JTBD the product actually owns. It also surfaces the honest competitive frame: what happens if the user solves this job with a centralized alternative? If the centralized alternative is fine and cheap, the protocol is building on thin ground.
Layer 3 — Product core. This is the operational heart of the product: the flows of money, data, and work that actually happen when the product is used. Who pays, who gets paid, who does the work, who bears the risk, where does value leak, where does it pool. The product core is a concrete diagram, not a pitch deck bullet. We return to this layer in detail below, because almost every tokenomics mistake happens here.
Layer 4 — Token mechanics. Only now does the token appear. The mechanic is whatever mechanism is needed to route value captured in Layer 3 back into the product loop — to pay for work, to align long-term holders, to coordinate governance over parameters that genuinely need coordinating. The rule of thumb: the mechanic must name a specific flow from Layer 3 that it touches. If it cannot, it is decoration.
For the full six-stage process that surrounds these four layers (research, stakeholder analysis, modeling, documentation), see the tokenomics design process.
Token-First vs Product-First: Why the Sequence Determines the Outcome
The same team, the same product idea, and the same available mechanics can produce a healthy token or a dead one depending solely on the order in which decisions are made.
The left column ends in decay because every step introduces friction that has to be covered by new buyers. The right column ends in a loop because each step produces a constraint that the next step satisfies, and value captured at the product layer keeps cycling back into the system.
Product Core: What It Actually Is
“Product core” is a working term for the operational description of the product — what actually happens when a user shows up. It is the layer where most tokenomics work goes wrong, because founders often describe the product in marketing terms and then hand the description to a tokenomist. Marketing terms do not have enough structure to derive mechanics from.
A usable product core description answers six questions:
| Dimension | The question it answers |
|---|---|
| Who pays | Which side of the product pays, with what, and how often |
| Who works | Which actors do productive work (validators, LPs, creators, curators, solvers) |
| Who bears risk | Who absorbs volatility, default, slashing, inventory risk |
| Value flow | The actual path of money from payer to worker, and every hop in between |
| Capture points | The hops where the protocol can skim without destroying the flow |
| Network effects | What makes the product compound — liquidity, data, reputation, directory |
Only after this table is filled in can the conversation shift to tokens. The capture points row is the most important: it tells you where value can legitimately flow into a token, and by extension, which mechanics are viable. A protocol with no capture points (free product, no fees, no scarce resource) has no mechanism-layer surface for a token to attach to — which typically means the project does not need a token, a situation handled in when you don’t need a token.
Mapping Product Core → Token Mechanics
Once the product core is explicit, the mechanic selection becomes a matching problem rather than a creative one. Every product archetype has a small number of mechanics that fit its value flow, and a much larger number that don’t. The matrix below is the compressed version of the matching table we use internally — rows are product-core archetypes, columns are mechanic classes.
A few patterns are worth naming explicitly.
Exchange/Marketplace (public illustrations: BNB, HYPE, LEO). The product core is a matching engine that charges fees. Capture points are the fee line and the liquidity layer. Fit mechanics: fee capture routed to buyback/burn, staking-gated discounts on fees, tiered access by token balance. Anti-fit: pure governance tokens — the governance surface is narrow (listing decisions, fee parameters), and users do not want to govern, they want to trade. A work-token model makes no sense because the exchange is the one doing the work.
L1/Infrastructure (ETH, SOL). Product core is secure block production and execution. Capture points are gas fees and the security budget. Fit mechanics: gas demand, staking for security, fee burn. Work-token logic applies to validators. Governance-only is weak because the constitutional parameters move rarely — governance is a by-product, not the product.
Asset issuer/Stablecoin (MKR, FXS). Product core is the issuance and backing of a liability. Capture points are the stability fee and the risk premium. Fit mechanics: fee accrual to token, staking-gated backstop (slashable insurance), governance over collateral parameters. Discounts are an anti-pattern — you do not want holders to get cheaper liabilities.
Yield aggregator / DeFi primitive (CRV, CVX and the ve-model family). Product core is a pool of capital directed by governance. The entire innovation here is that the mechanism is the product — LPs, boosters, and bribers participate because the ve-lock structure directs emissions, and that directionality has market value. Discounts are meaningless because there is no consumer-facing fee; the token holder is the producer.
DePIN (Helium, Filecoin). Product core is a network of physical or virtual resource providers. Capture is at the resource-purchase layer, but the immediate need is to subsidize coverage before demand is there. Fit mechanic: work-token emission against verified resource delivery, with a payment coin (often separate) to avoid pricing instability for buyers.
Attention/Media. Product core is user attention, which is not a financial flow by default. Most token attempts fail here because attention does not naturally flow into a capturable line — it has to be wrapped in advertising, subscriptions, or creator economics first. The matrix is mostly “conditional” for this archetype: a token can work, but only after the attention has been converted into something that looks like one of the other archetypes.
For how individual mechanisms compose once selected, see mechanism design and the underlying utility models.
Archetype Deep Dive: The Exchange/Marketplace Loop
To make the mapping concrete, one archetype worked through end to end. The exchange/marketplace is the most commercially mature product-token pairing in the industry, and it shows the full loop from fee to capture to reinforcement.
Every arrow in that diagram is a decision the team has to make explicitly. How much of the fee line goes to each bucket is not a matter of taste — it follows from where the product is in its life cycle. Early in the curve, the bottleneck is liquidity and retention, so the split leans toward discount and staker yield. Later, as competitive advantage shifts from liquidity to brand, buyback/burn becomes more efficient per dollar because the marginal user is no longer price-sensitive.
The split itself is small arithmetic. What matters is that it moves with the product. The same fee line at different life-cycle stages should not be split the same way. Below — an illustrative split for an exchange with $10M in monthly fees, shown across three stages:
| Stage | Buyback | Stakers | Insurance | Discount | Rationale |
|---|---|---|---|---|---|
| Early — liquidity-starved, price-sensitive users | 15% ($1.5M) | 30% ($3.0M) | 10% ($1.0M) | 45% ($4.5M) | Retention is the bottleneck. Discount is the cheapest way to defend volume; buyback wastes fee revenue on a thin holder base. |
| Growth — volume established, brand forming | 40% ($4.0M) | 30% ($3.0M) | 10% ($1.0M) | 20% ($2.0M) | Balance: buyback starts working as the float base broadens; discount still matters but less. |
| Mature — brand-driven demand, price-insensitive | 55% ($5.5M) | 25% ($2.5M) | 15% ($1.5M) | 5% ($0.5M) | Marginal user is no longer fee-shopping. Buyback is the most efficient use of captured value; insurance grows to protect the franchise. |
The real version adds market-impact limits on the buyback, a yield cap on stakers, and a floor on the insurance fund. But the key point is that the split is a knob the product team controls, and the right position of that knob is a product decision, not a token decision. It answers the question: what does the product need most right now, given how users are actually behaving?
Anti-Patterns
Four mistakes show up across the majority of failed tokens. All of them are consequences of skipping the product-core layer.
Anti-patterns to avoid
- Forced utility. A feature is gated behind the token for the sole purpose of creating token demand. If removing the gate would not materially harm the product, the gate is extracting value from users rather than capturing it.
- Governance-only tokens. The only thing the token does is vote on parameters that rarely change and usually don’t matter. Voter turnout collapses, and the token has no price floor other than speculation.
- Copy-paste ve-lock. The ve-model is adopted because it worked for a DeFi primitive, applied to a product that is not a DeFi primitive. Locked supply goes up, product metrics do not, and the holder base turns into short-sighted emission farmers.
- Discount as the entire thesis. The token gives a fee discount and nothing else. This is a fiat subsidy with extra steps — and fiat subsidies are cheaper, because they don’t require a token treasury to defend a price.
Design Checklist
Ten questions to run through before a single line of allocation is drafted. If any answer is “we haven’t decided,” you are not ready to design the token.
Product-led tokenomics checklist
- JTBD in one sentence. Can you state the user’s job in a single sentence, without mentioning the token?
- Competitive alternative named. Which specific centralized or on-chain alternative solves this job today, and why is yours better?
- Value flows drawn. Do you have a diagram of who pays, who works, and where money hops?
- Capture points identified. At which hops can the protocol legitimately skim without killing the flow?
- Mechanic-to-flow binding. For every mechanic you plan to include, can you point at the exact flow it touches?
- “Delete the token” test. If the token were removed tomorrow, which product functions would genuinely stop working?
- Minimal mechanic set. Is this the smallest set of mechanics that implements your capture strategy, or are there borrowed ones?
- Governance surface honest. Is there a real parameter space worth coordinating over, or is governance ornamental?
- Life-cycle fit. Does your split (buyback vs yield vs discount vs insurance) match where the product actually is in its curve?
- Reinforcement loop closes. Can you trace captured value back into the product loop as retention, new users, or reduced cost of capital?
If all ten answers are solid, the allocation table and emission curve become straightforward — they are now serving a specified purpose, not inventing one.
Designing tokenomics from a real product?
We work with founders and product teams to translate product architecture into token mechanics that reinforce the business, not fight it.
Talk to us