Get Tokenomics

Tokenomics design
from first principles

Token utility, allocation, vesting, mechanisms, stakeholder incentives, launch strategy — designed against your actual product, drawn from a 240+ patterns library, every choice defended in writing.

Send a brief Book a discovery call
40+
tokenomics projects
240+
patterns library
6
design dimensions

What we design

Six architectural layers. Each choice tied to a specific stakeholder behaviour or product mechanic. Delivered as a design document structured for three audiences — CMO, CPO, CTO.

Token utility

Why anyone holds this token. Value-accrual mechanisms — fees, governance, access, burn, staking, collateral, redemption. Designed against concrete product behaviour, not abstract "store of value" claims.

Allocation strategy

Percentages across team, investors, treasury, community, ecosystem, public. Each tied to capital needs, milestones, and stakeholder leverage. No 20-30-50 splits because that is what the last project did.

Vesting and unlock design

Cliff, slope, milestone-based vs time-based. Founders locked through product-market fit, ecosystem unlocks tied to usage growth — not calendar dates.

Mechanism design

Staking, fees, governance, treasury, sinks and sources. Selected from our 240+ patterns library, specified parameter-by-parameter with illustrative calculations showing how each responds.

Stakeholder incentives

What each stakeholder — founders, investors, users, validators, LPs — needs to do for the system to work, and the payoff that aligns them with that behaviour.

Token launch strategy

TGE structure, fundraise rounds, public sale mechanics (bonding curve, LBP, IDO, direct, hybrid), price discovery. Against your capital needs and regulatory context — not a default launch template.

How we work

From a discovery call to a delivered design document in five steps. Every step ends with a written artefact you can challenge before we move forward.

?
01

Discovery

Product, business model, stakeholder map, capital needs, regulatory constraints. What problem the tokenomics needs to solve, and what fails if we get it wrong. End state: a written design brief both sides agree on.

ProductStakeholdersConstraints
TokenAlloc %VestingTeam15%24 moInvestors20%12 moCommunity40%36 moTreasury25%48 mo
03

Architecture proposal

Allocation, vesting, utility, mechanisms drafted as a design document. Every choice explained — why this mechanism, why this percentage, why this curve. The document is structured so a CMO, a CPO, or a CTO can read their section without us in the room and form an independent view.

Design docRationale per choiceDefensible
modelreportdeckdashboard
05

Documentation

Final design document, structured by audience — CMO sections (utility, narrative, launch), CPO sections (mechanic flows, stakeholder incentives), CTO sections (technical specifications, parameter ranges, integration points). PDF plus Markdown source, presentation walk-through. Modelling is a separate engagement, commissioned when numbers need to move.

By-audiencePDF + MarkdownWalk-through
sourcesnapshotinput
02

Pattern selection

From the 240+ patterns library, we shortlist mechanics that fit your product context. Each candidate pattern comes with case-studies showing where it has worked, where it has broken, and what the trade-offs are.

240+ patternsTrade-offsPrecedents
basebull/bear
04

Mechanism specifications

Each mechanic specified parameter-by-parameter, with illustrative calculations to show how it responds. How a bonding curve prices a buy. How a fee split flows under different volume. How staking yield scales with TVL. Not modelling, not simulation — just enough math to make the behaviour legible to engineering and product.

CTO-grade specsIllustrative calcIntegration points

Have a product but no tokenomics yet?

Send what exists — product spec, business model, roadmap, anything. We will come back with a design proposal: what mechanics fit your product, what allocation logic makes sense, where to start.

Request a quote

Sectors we design for

Real mechanics from our 240+ patterns library, weighted toward design choices most often relevant for each sector.

DeFi

Bonding-curve mintsLiquid stakingLending and collateralSubordination tranchesFee-switch and value accrual

GameFi

Action rewards designStreak and progression mechanicsGenesis NFT stagingLootbox economicsNFT vs in-game token boundaries

RWA

Ownership NFTsCommodity tokensSecurity rev-share waterfallsTokenized stock dividendsOff-chain reserves design

DePIN

Mining reward designIoT-device mint formulasProof-of-compute collateralASIC fleet economicsMulti-asset mining

L1/L2

PoS staking designInflation vs staking curveEIP-1559 dynamic pricingValidator reward designValue-transfer fee design

Governance

ve-tokenomics designQuorum mechanicsQuadratic votingVoting committeesFee-switch governance

Selected case studies

Engagements where the deliverable was a design document, not a spreadsheet.

Trading fees100%Stakers40%Treasury35%Insurance25%

DeFi lending protocol — bonding curve plus subordination sink

Designed a bonding-curve mint paired with three-tier subordination as a structural token sink, plus a triple-burn mechanic for cashback utilization. Allocation, vesting, mechanism specifications detailed enough for engineering to implement without further design rounds.

PlayerEarnMarketBurnclosed loop

SocialFi platform — dual-token system for sports communities

Designed a dual-token system across 2.1B tokens: club-tier structure, fan funnel mechanics, buyback-and-burn flow. Each mechanic tied to a specific stakeholder behaviour — fans, clubs, platform — not pasted from a generic fan-token template.

Trading fees100%Stakers40%Treasury35%Insurance25%

Multi-product exchange — three competing token concepts

Stage 1 design framework for a 13-product crypto-fintech: three token concepts (real-yield, loyalty, B2B utility) with FDV ranges, capital needs, and stakeholder leverage mapped per concept. Architectural decision document delivered before any modelling.

FAQ

When do you need tokenomics design?
Four common moments. Pre-TGE — primary case, designing tokenomics for a new project from first principles before launch. Pivot or relaunch — existing tokenomics did not work and we redesign rather than patch. New mechanic — adding a fee switch, a staking module, or a new sink to a live protocol; even one mechanic deserves design before deployment. Pre-fundraise — investors want to see the architecture, not just numbers, and a design document gives them what to evaluate.
How long does design take?
A focused single-mechanic design — for example a new fee-switch on a live protocol — runs 1 to 3 weeks. Full tokenomics design from first principles for a pre-TGE project runs 4 to 8 weeks depending on product complexity and stakeholder count. Combined design plus modelling typically takes 6 to 12 weeks. We give a tighter estimate after the discovery call.
What deliverables ship?
A written design document (PDF plus Markdown source), structured by audience: CMO sections — token utility, market narrative, launch strategy. CPO sections — mechanic flows, stakeholder incentive logic, allocation rationale. CTO sections — technical specifications, parameter ranges, integration points, illustrative calculations. Plus an allocation table with rationale per percentage, a vesting and unlock schedule, and a presentation walk-through. Each role can read its section and act on it without us in the room.
Are there calculations in the design document?
Illustrative calculations only — enough math to make each mechanic legible. How a bonding curve prices a buy of size X. How staking yield scales with TVL. How a fee split flows under different volume assumptions. The point is showing the behaviour to a CPO or CTO reading the spec, not producing a working model. Stress-tests, sensitivity tables, dashboards, Monte Carlo — those are modelling and simulation work, separate engagements.
How is tokenomics design different from tokenomics modelling?
Different products, different deliverables. Design answers what to build — which mechanics, which allocation percentages, which vesting curves. The deliverable is an architectural document with illustrative math. Modelling answers what numbers does that produce at scale — implementing the design as a working spreadsheet with formulas, sensitivity tables, scenario toggles, and dashboards. Design typically comes first, modelling implements it. Most engagements commission both together. We sell them as separate deliverables so each is defensible on its own.
Can I just copy a similar protocol's tokenomics?
Technically yes, and the failure pattern is well-documented. Competitor tokenomics work for their product, their stakeholders, their capital structure, their regulatory context. Yours differs on at least three of those four. We have audited tokenomics that copied a successful protocol and broke for exactly this reason — the architecture was right, the context was wrong. Design from first principles avoids that.
Can you design tokenomics without a fully-built product?
Partially. With a strong product spec, a clear roadmap, and identified core stakeholders, we can design defensible architecture. With only a vision deck and no product detail, the design rests on assumptions — we name them in writing, but the resulting tokenomics will need revision once the product is real. Best results come when at least the core mechanics are built or specified in detail.
Do you sign NDAs?
Yes, before any project material is shared. Standard mutual NDAs — we have a template, or we sign yours. Design material is sensitive because it reveals strategic positioning before launch.

Designing from first principles?

Tell us about the product. We will come back with a design proposal — patterns that fit, allocation logic that defends itself, and what to think about first.

Send a brief Book a discovery call