What is token allocation?

Token allocation is the division of total token supply across stakeholder buckets such as community, team, investors, treasury, and liquidity. A complete allocation design is a table where every bucket carries a percentage, a token count, a vesting cliff, a vesting length, and a launch-day unlock, all summing to 100%. The balance between community and insiders is the first signal a serious investor reads, because a model that over-allocates to insiders tends to dump on the people it needed to keep.

What is the difference between FDV and market cap?

Fully-diluted valuation is the token price multiplied by the maximum or total supply, while market cap is the price multiplied by the circulating supply only. FDV counts the tokens still locked in vesting, so it shows the real sticker price; market cap shows what is in the market today. A low market cap sitting under a much larger FDV is a warning that future unlocks will weigh on the price.

A token generation event is the moment a token is first created and begins to exist and trade. It is the launch line everything before it builds toward and everything after it lives with, because most errors baked in at the TGE are permanent. We stress-test the float and liquidity before the TGE rather than discovering the problems live.

What is a vesting cliff?

A vesting cliff is a period after a token launch during which an allocation bucket is fully locked and nothing unlocks, followed by the point where vesting begins. Cliffs exist to stop early investors and team members from selling on day one. The risk is a cliff wall, where several buckets end their cliffs in the same month and concentrate sell pressure into a single window, which is one of the most common preventable causes of a post-launch price collapse.

What is the difference between staking and restaking?

Staking is locking tokens to secure a single proof-of-stake network or qualify for rewards, with slashing risk tied to that one network. Restaking reuses already-staked collateral to secure additional services beyond the base chain, earning extra fees in exchange for taking on extra slashing exposure. The same capital backs multiple obligations at once, which is the source of both the higher yield and the correlated risk a restaking design has to reserve against.

What is a tokenomics audit?

A tokenomics audit is an independent, third-party review of a token's economic model that finds the risks capable of breaking it before a raise or launch. A real audit runs more than a dozen distinct quantitative analyses covering vesting, liquidity, investor ROI, and mechanism design, each with its own severity-rated risk table, and ends in a verdict with prioritized recommendations. It is the diligence you run on yourself before investors run it on you.

What is the difference between a utility token and a security token?

A utility token is consumed inside a product to access a service or pay a fee, so its demand tracks usage and it triggers a light regulatory regime. A security token represents a claim on profits, revenue, or a managed return, so holders expect to profit from the efforts of others, which triggers full securities law including prospectus and disclosure obligations. The classification is determined by what the token does and the rights it carries, not by what it is called in the marketing.

What is the Howey test?

The Howey test is the US framework for deciding whether an instrument is an investment contract, and therefore a security, across four prongs: an investment of money, in a common enterprise, with an expectation of profits, derived from the efforts of others. A token that satisfies all four prongs is likely a security. We design architectural choices that reduce a token's exposure to each prong, then hand counsel a brief of what to confirm, rather than giving a legal opinion ourselves.

Tokenomics Glossary: 125 Terms That Decide Whether a Token Works

What This Glossary Is

This is a working tokenomics glossary, not a dictionary of buzzwords. Every term here is one we use in real engagements, defined the way we define it for clients: plainly, with the design consequence attached, because a definition that does not change a decision is just trivia.

The terms are grouped into thirteen categories that follow how a token model is actually built. We start with what a token legally is, move through supply and distribution, valuation, launch and markets, governance, staking and yield, mechanism design, then the audit and risk vocabulary, and finish with the specialist language of real-world assets, DePIN, restaking, compliance, and economic simulation. Where a term has a full page behind it, we link to it.

A note on how we classify tokens. There are five legal buckets, and only five, set by what a token represents and the rights it carries. Governance is a feature a token can carry, not a sixth type. Everything downstream follows from that first classification.

Token Types and Classification

The first axis of classification is what a token legally is, determined by what it represents and the rights it carries. There are five buckets, and only five. Governance is a feature a token can carry, not a sixth type. See tokenomics design for how classification drives the whole architecture.

Asset / commodity token: An asset or commodity token represents one-to-one ownership of a real underlying asset held in custody, redeemable, with no yield attached to the token itself. It triggers commodity oversight, AML obligations, and custody and audit requirements. This is the bucket for tokenized gold and most real-world asset designs. Design consequence: we keep it a pure ownership claim, because the moment it pays a yield it drifts toward the security bucket.
Security token: A security token represents a claim on profits, revenue, equity, or a managed return. If holders expect to profit from the efforts of others, the token is almost certainly a security. It triggers the heaviest regime: prospectus obligations, accredited-investor rules, and disclosure requirements. Some projects belong here and should embrace it; the danger is the project that lands here by accident.
Payment / stablecoin token: A payment or stablecoin token is designed to be used as money, typically pegged to fiat or a fiat basket. It triggers e-money and stablecoin regulatory frameworks, which have tightened considerably. Design consequence: we ask whether the project genuinely needs to issue money, or whether an existing stablecoin does the job.
Utility token: A utility token is consumed inside the product to access a service, pay a fee, or unlock a function. Its demand should track usage: the more the protocol is used, the more the token is needed. It triggers the lightest, residual regime of consumer protection, AML, and marketing rules. This is the bucket most projects want, and the bucket most projects misclassify themselves into without earning it.
NFT: A non-fungible token represents a unique, non-fungible item or right. Its classification depends entirely on what the underlying item or right represents, so a piece of digital art and a tokenized claim on a building can both be NFTs and sit in completely different regulatory positions.
Governance as a feature: Governance is a capability a token can carry, not a sixth bucket in the classification. A token that confers only voting rights, with no usage demand underneath it, is the single most common failure pattern we see: a governance-only token marketed as a utility token. Its worth rests entirely on whether the governance rights are meaningful, which in practice they frequently are not.
Token standard: A token standard is the technical contract interface a token implements, such as the common fungible-token standard or the permissioned standards built for regulated securities. The standard determines which venues can list the token, what compliance logic can live in the contract, and how composable the token is with DeFi. Picking the wrong standard narrows venues and widens spreads, so we justify the choice and document why the alternatives were rejected.

Supply and Distribution

How tokens are allocated and released over time. Poor supply-side decisions kill the best mechanism design, which is why we treat them as existential. See token allocation and vesting for the full discipline.

Token allocation: Token allocation is the division of total token supply across stakeholder buckets such as community, team, investors, treasury, and liquidity. A full allocation design is a table where every bucket has a percentage, a token count, a cliff, a vesting length, and a TGE unlock, summing to 100%. The balance between community and insiders is the first thing a serious investor checks.
Vesting schedule: A vesting schedule is the timetable that controls when each allocation bucket can begin selling its tokens. It is not a legal formality; it is the most powerful tool a founder has for managing sell pressure. Design consequence: we model it month by month to map exactly when each stakeholder bucket unlocks.
Vesting cliff: A vesting cliff is a period after the token launch during which a bucket's tokens are fully locked and nothing unlocks, followed by the start of vesting. A cliff that is too short on insider allocations, or that ends at the same moment as several others, concentrates sell pressure.
Linear vesting: Linear vesting releases a bucket's tokens in equal increments over the vesting period after the cliff, rather than in lumps. It smooths sell pressure into a predictable stream, which is why most team and investor buckets use it. The alternative, milestone vesting, ties unlocks to delivery rather than the calendar.
Token unlock: A token unlock is the moment a vesting schedule releases tokens from a locked bucket into circulation, where they become legally sellable. Unlocks are the calendar of future sell pressure, so we map every one of them. The danger is several large unlocks landing in the same month.
Cliff wall: A cliff wall is a month in which multiple vesting buckets begin unlocking simultaneously, concentrating sell pressure into a single window. It is a core risk the vesting analysis is designed to catch and prevent, because a cliff wall can erase a price chart in days.
Emission schedule: An emission schedule is the planned release of new tokens into circulation over time through rewards, incentives, and inflation, separate from the vesting of pre-allocated supply. Every emitted token is future sell pressure the design is choosing to create. We model the full horizon so the heaviest emission year is matched to demand that can absorb it.
Emissions taper: An emissions taper is the schedule by which token emissions decline over time rather than holding flat or rising. A smooth taper keeps the peak-to-average emission ratio low, which matters because every emitted token is future sell pressure the design is choosing to create.
Inflation: Token inflation is the rate at which total supply grows through new emissions, expressed annually. Inflation funds rewards and incentives, but it dilutes existing holders and creates sell pressure, so it has to be paid for by demand that grows at least as fast. A design that inflates faster than it builds sinks is printing its own decline.
Distribution archetype: A distribution archetype is a project-type template that sets defensible ranges for each allocation bucket, vesting length, and TGE float percentage. An RWA protocol and a DePIN network have different archetypes, so we calibrate the allocation to the archetype rather than to a generic rule of thumb.
Fair token distribution: A fair token distribution keeps the community allocation as the largest combined block and avoids concentrating supply in insiders and investors. It is partly an advisory check, not just a hard rule, because the optics of an insider-heavy table will sink a raise even when the math passes. We flag the balance explicitly in every distribution design.
Operator selling: Operator selling is the recurring sell pressure created when a network's operators or validators must routinely convert earned tokens to cover real-world costs such as hardware and electricity. In any network where participants have off-chain expenses, this is structural sell pressure the demand side has to absorb.

Valuation and Metrics

The numbers used to size, compare, and sanity-check a token economy. Most of them are easy to quote and easy to misread, which is why we decompose them. See tokenomics audit.

Fully-diluted valuation (FDV): Fully-diluted valuation is the token price multiplied by the maximum or total token supply, the market cap the project would have if every token were circulating. FDV is the honest sticker price, because it counts the supply still locked in vesting. A low circulating market cap sitting under a huge FDV is a warning that future unlocks will weigh on price.
Market capitalization: Market capitalization is the token price multiplied by the circulating supply, the value of tokens actually in the market today. It moves with both price and unlocks, so a flat price with a rising market cap usually means new supply is entering circulation. We read it alongside FDV, never alone.
Circulating supply: Circulating supply is the number of tokens currently in the market and freely transferable, excluding locked, vesting, and treasury-held tokens. It is the denominator for market cap and the input that grows on every unlock. The gap between circulating and total supply is the future dilution the chart has not priced yet.
Total supply: Total supply is every token that exists, including locked and vesting tokens but excluding any that have been permanently burned. It sits between circulating supply and max supply, and the distance from circulating to total is the pipeline of tokens still to unlock.
Max supply: Max supply is the hard ceiling on how many tokens can ever exist, when one is defined. A fixed max supply is a credible scarcity commitment; an uncapped or governance-mutable max supply is not, and we flag the difference because holders price the two very differently.
FDV/raise ratio: The FDV-to-raise ratio is fully-diluted valuation divided by total capital raised, a capital-efficiency and dilution sanity check measured against a healthy band. A ratio outside the band signals either a valuation that will be hard to grow into or a raise that gives away too much.
Total value locked (TVL): Total value locked is the dollar value of assets deposited in a protocol's contracts, used as a rough measure of adoption and trust. It is a real signal and a gameable one, because incentive-farmed TVL leaves the moment the incentives stop. We treat it as one input, not the scoreboard.
Market-cap-to-TVL ratio: The market-cap-to-TVL ratio compares a protocol's token valuation to the value it actually secures or holds, a rough check on whether the token is priced ahead of its underlying activity. A high ratio can mean the market is pricing in future growth, or that the token is overvalued relative to what it does. The number only means something against comparable protocols.
Token velocity: Token velocity is how quickly a token changes hands relative to its market cap; high velocity means holders pass it on rather than hold it. High velocity suppresses price because nobody wants to sit on the token, which is why pure medium-of-exchange tokens struggle to hold value. Design consequence: we engineer stock sinks that give holders a reason to keep the token rather than spend it immediately.

Launch and Markets

How a token comes to market and how it trades on day one and beyond. Poor liquidity planning is one of the most common causes of a price collapse at launch. See token launch strategy for the full discipline.

Token generation event (TGE): A token generation event is the moment a token is first created and begins to exist and trade. It is the launch line everything before it builds toward and everything after it lives with. Design consequence: we stress-test the TGE before it happens, because almost every error baked in at TGE is permanent.
TGE float: TGE float is the supply circulating at the token generation event, the moment the token first exists and trades. The headline figure is misleading on its own, which is why we decompose it into what can actually be sold.
Effective sellable float: Effective sellable float is the portion of the TGE float that can realistically be sold, after excluding liquidity-pool tokens locked in the pool and full-price buyers who have no incentive to dump. This is the number that predicts real launch-day sell pressure, not the headline float.
Initial coin offering (ICO): An initial coin offering is a public token sale conducted directly by the project, the earliest mainstream fundraising format and the one most associated with the unregulated era. Most jurisdictions now treat an open public sale as a securities offering by default, so the format carries real classification risk. We design any public sale against the regulatory regime, not around it.
Initial DEX offering (IDO): An initial DEX offering launches a token directly into a decentralized exchange liquidity pool, often through a launchpad. It gives instant tradability and price discovery, but it exposes the token to launch-day sell pressure with no gatekeeper, which is exactly why the float and liquidity planning have to be right first.
Initial exchange offering (IEO): An initial exchange offering is a token sale hosted and vetted by a centralized exchange, which handles listing and some compliance screening. The exchange's involvement adds credibility and reach at the cost of fees and dependence on a single venue's rules. The classification of the token itself does not change because an exchange ran the sale.
Decentralized exchange (DEX): A decentralized exchange is a venue where tokens trade peer-to-contract through onchain liquidity pools rather than a central order book. It is where most new tokens first trade, which makes pool sizing and range design a launch-critical decision.
Automated market maker (AMM): An automated market maker is the contract logic that prices trades on a decentralized exchange using a formula over pooled reserves rather than matching buyers to sellers. The AMM formula decides how much price moves per trade, which is why we model the pool directly to find the largest trade it can absorb at acceptable slippage.
Liquidity pool: A liquidity pool is the paired reserve of two tokens that an AMM trades against; its depth sets how much a given trade moves the price. A shallow pool means large trades crater the price, so pool size is a direct lever on launch-day stability. We size the pool against the trades real users will actually execute.
Concentrated liquidity (V3) versus constant-product (V2): Constant-product liquidity spreads a budget evenly across all possible prices; concentrated liquidity puts that same budget inside a tight band around the trading price. Concentrating delivers far more effective trading depth for the same capital, at the cost of the liquidity disappearing if the price exits the band. The capital-efficiency gap between the two can be an order of magnitude.
Liquidity depth: Liquidity depth is how much capital sits in a pool near the current price, which determines how large a trade can execute without moving the price much. Depth, not headline TVL, is what a large buyer or seller actually feels. We work backward from target trade sizes to the depth required, then flag the gap to planned liquidity.
Slippage: Slippage is the difference between a trade's expected price and the price it actually executes at, caused by the trade moving along the liquidity curve. We model slippage at small, medium, and large trade sizes to find the maximum trade a pool can absorb at acceptable thresholds, typically 2%, 5%, and 10%.
Price impact: Price impact is how far a single trade moves the market price, a direct function of trade size against pool depth. It is the cost a large trade imposes on itself, and it is what separates a pool that can absorb institutional size from one that cannot. We chart it across trade sizes so the launch team knows the pool's real ceiling.
Market maker: A market maker is a party that continuously quotes both buy and sell prices to keep a market liquid and spreads tight. On a token launch, market making can come from a professional desk or from protocol-owned liquidity in an AMM. We plan when professional depth and OTC capacity need to come online, while treating contracts with specific desks as outside our scope.
Buy pressure: Buy pressure is the recurring demand, expressed in dollars per month, required to absorb token sell pressure and hold a target price. We compute the buy pressure needed to sustain the launch price under a worst-case assumption, then check whether the token's utility sinks can plausibly generate it.

Governance and DAOs

How token holders make decisions, and the structures that keep those decisions from collapsing into a single large holder's preferences. See tokenomics design.

Governance: Token governance is the system by which holders propose and vote on changes to a protocol, from parameters to treasury spending to upgrades. Governance is a feature a token can carry, not a token type, and it only has value when the rights are meaningful and exercised. A governance-only token with no usage demand underneath it is the most common failure pattern we see.
DAO: A decentralized autonomous organization is a group that coordinates and allocates resources through onchain governance rather than a traditional corporate structure. A DAO's legitimacy rests on whether participation is real and whether voting power is distributed, not on the label. Design consequence: we treat low turnout and whale capture as the default risks to engineer against.
Quorum: Quorum is the minimum participation required for a governance vote to be valid. Set it too high and nothing passes; set it too low and a small, motivated group can push proposals through. The right quorum is calibrated to realistic turnout, which is usually far lower than founders expect.
Timelock: A timelock is a mandatory delay between a governance decision passing and it taking effect onchain. It gives holders time to react, exit, or contest a malicious or mistaken proposal before it executes. We specify upgrade governance through a timelock paired with a multisig precisely so no single actor can change the rules instantly.
Multisig: A multisignature wallet requires several independent keys to approve a transaction before it executes. It removes the single point of failure of one key controlling funds or upgrade rights, and it is the standard way we recommend governing admin powers. The number of signers and their independence is what makes it real rather than theater.
Delegation: Delegation lets a token holder assign their voting power to another participant who votes on their behalf. It raises effective participation when most holders will not vote themselves, but it concentrates power in delegates, which has to be watched. Healthy delegation is distributed across many active delegates, not captured by one.
Square-root (quadratic) voting: Square-root, or quadratic, voting scales governance voting power by the square root of stake, so larger holders still have more influence but whale dominance is dampened. It is one tool for keeping governance from collapsing into a single large holder's preferences.
Vote-escrowed (ve) tokenomics: Vote-escrowed tokenomics grants more voting power and rewards to holders who lock their tokens for longer, trading liquidity for influence. It aligns governance with long-term holders and creates a stock sink, but it can also entrench early lockers and invite vote-buying markets. We weigh the alignment benefit against the centralization it can produce.

Staking, Yield, and Restaking

How holders lock tokens to secure a network or earn a return, and the language of the yield they receive. See LST and LRT tokenomics for the restaking verticals.

Staking: Staking is locking tokens to help secure a proof-of-stake network or to qualify for protocol rewards and access. It pulls supply out of circulation, which makes it a stock sink, and it ties a holder's return to the network's health. Design consequence: we treat staking demand as real only when it is forced by access or security, not when it is a yield bribe that leaves the moment emissions stop.
Validator: A validator is a node operator that stakes collateral to propose and confirm blocks on a proof-of-stake network, earning rewards and risking penalties. Validators carry the security of the chain and the slashing risk that backs it. A network where a few operators run most validators carries concentration risk regardless of how decentralized the token looks.
Slashing: Slashing is the protocol-enforced penalty that destroys part of a validator's staked collateral for misbehavior such as downtime or double-signing. It is what makes staked security credible: the validator has real money at risk. Slashing risk is also the loss a staking or restaking design has to reserve against before it reaches depositor funds.
Liquid staking token (LST): A liquid staking token is a tradable receipt for staked assets that lets the holder keep liquidity while still earning staking rewards. It solves the problem of staked capital being locked and unusable, and it is the base layer the restaking verticals build on.
Liquid restaking token (LRT): A liquid restaking token is a tradable receipt for restaked collateral that earns base staking rewards plus the fees from the services that collateral secures. Its yield is a composite, not a single rate, and it carries the combined slashing risk of every service it backs.
Restaking: Restaking is reusing already-staked collateral to secure additional services beyond the base chain, earning extra fees in exchange for taking on extra slashing exposure. The same capital backs multiple obligations at once, which is the source of both the yield and the correlated risk. Design consequence: we size the slashing reserve against multi-service exposure, not a single vector.
Rebasing token: A rebasing token is a liquid staking token whose holder balance grows automatically as staking rewards accrue, increasing the token supply to distribute yield. It feels intuitive but it breaks DeFi composability, because lending protocols and AMMs assume static balances per position.
Exchange-rate token: An exchange-rate token is a liquid staking token whose holder balance stays fixed while the token appreciates in price relative to the underlying asset as rewards accrue. Most DeFi-native designs use this model because the static balance is composable with AMMs, lending protocols, and derivatives markets.
Actively validated service (AVS): An actively validated service is a network or service that buys security from a restaking marketplace; operators validate it using staked collateral and earn a fee, and each service sets its own slashing conditions. In a restaking position, the same collateral backs multiple service obligations at once.
Restaking yield: Restaking yield is the combined return earned by a liquid restaking token holder, composed of base staking rewards plus the operator fees paid by each service secured. It is a composite, not a single rate, and it depends entirely on adoption of the secured services, which is why marketing un-launched fees as live yield is a failure pattern.
APR versus APY: APR is the simple annual rate of return without compounding; APY is the annualized rate after compounding rewards over the period. APY is always at least APR and usually higher, so quoting APY makes a yield look bigger than the same yield quoted as APR. We hold designs to honest, like-for-like rate disclosure because the gap is where misleading yield marketing lives.
Time-weighted staking rewards: Time-weighted staking rewards are weighted by both stake size, dampened by a square root, and the duration staked, designed to defeat just-in-time staking where capital appears the moment before a reward and leaves the moment after.
Slashing reserve: A slashing reserve is a capital buffer a staking or restaking protocol maintains to absorb validator penalty losses before they reach depositor funds. It can be funded through mandatory operator collateral or a treasury backstop, and for restaking it has to be sized against multi-service exposure rather than a single slashing vector.
Operator concentration: Operator concentration is the degree to which a small number of node operators dominate validation within a network or restaking marketplace. High concentration amplifies correlated slashing risk, because a shared client bug or operational failure can trigger simultaneous penalties across everything those operators validate.

Mechanism and Flywheel Design

How a token creates and captures value, and why anyone holds it. See tokenomics design for the full discipline.

Token utility: Token utility is the concrete job a token does inside its product: the function it unlocks, the fee it pays, the access it grants. Real utility forces demand; "access" or "ecosystem" claims with no mechanism behind them are decoration. Design consequence: we test utility by naming who is doing what, paying what, on which day.
Value accrual: Value accrual is the mechanism by which protocol success translates into token value, through fees routed to the token, supply removed from circulation, or rights that become more valuable as usage grows. Without a value-accrual channel, a protocol can succeed while its token does nothing. We make the accrual path explicit rather than assuming the token rises because the protocol does.
Economic flywheel: An economic flywheel is the self-reinforcing loop connecting protocol usage, token demand, token value, and protocol growth: usage drives demand, demand supports value, value funds growth, growth drives more usage. The design work is engineering that loop so it actually closes, rather than asserting it with arrows on a diagram.
Faucets: Faucets are the issuance mechanisms that emit tokens into circulation: rewards, emissions, and incentives. Every faucet is future sell pressure the design is choosing to create. There is no such thing as a free emission; it is a liability you are scheduling.
Sinks: Sinks are the utility mechanisms that pull tokens out of circulation. Flow sinks create recurring buy pressure, such as a fee paid in the token or a per-transaction burn. Stock sinks create persistent lockup, such as staking for access or posting the token as collateral. Every faucet must be matched to a sink that can absorb it, or the emissions are just inflation with extra steps.
Demand sink: A demand sink is any mechanism that creates real, recurring demand to acquire or hold a token. Flow demand is recurring buy pressure such as paying a fee in the token; stock demand is persistent lockup such as staking for access. A platform token's entire value capture is engineered through these, which is why a token without a designed sink has no floor.
Burn: A token burn permanently removes tokens from supply by sending them to an unspendable address. Burns can be a flow sink, where a share of fees is burned per transaction, creating a deflationary pull tied to usage. A burn only matters if it is funded by real activity; a one-off marketing burn changes nothing structural.
Buyback: A buyback is the protocol or treasury using revenue to repurchase its own token from the market, often paired with a burn. It routes business success back into token demand, but it only holds up if the revenue funding it is sustainable. We model buyback strategy against the realistic revenue, not the optimistic case, before recommending it.
Token velocity problem: The token velocity problem is the tendency of a pure medium-of-exchange token to lose value because holders spend it immediately rather than hold it, so it never captures the value flowing through it. The fix is a stock sink, a reason to hold, that lowers velocity. Design consequence: we engineer holding incentives into any token that would otherwise just pass through hands.
Mechanism design: Mechanism design is the engineering of the rules, incentives, and flows that make a token economy behave the way it should under self-interested participants. It is the core technical work of tokenomics: defining the operating loop, the faucets and sinks, the value-accrual path, and the invariants.
Token-necessity test: The token-necessity test is a four-question test we run before designing any mechanism: does the token coordinate independent participants the project does not control, would the product break without it, does it do a job a stablecoin cannot, and does real activity create demand for it? When the honest answer to any question is no, "no token" is a valid and valuable conclusion.
Utility test: The utility test is a concrete check on whether a token's utility is real: name who is doing what, paying what, on which day. If the answer cannot be specified, the utility is not real yet, no matter how confidently the whitepaper describes it.
Two-token separation rule: When a project genuinely warrants two tokens, the asset token and the platform token almost never share a classification and must never overlap: a platform token's demand must never contaminate an asset token's peg. That separation is the entire reason for using two tokens instead of one. The test is independence: if the platform token went to zero, does the core product still work?
Supply invariant: A supply invariant is the rule the whole system depends on: circulating token supply must never exceed verified backing. It is enforced automatically at the contract level, so a mint that would violate it simply reverts. This is what makes "backed one-to-one" a verifiable fact rather than a marketing line.

Audit and Risk

The vocabulary of finding what can break a token model before it does. See tokenomics audit for the full discipline.

Tokenomics audit: A tokenomics audit is an independent, third-party review of a token's economic model that finds the risks capable of breaking it before a raise or launch. A real audit runs more than a dozen distinct quantitative analyses, each with charts, key insights, and a severity-rated risk table, and ends in a verdict with prioritized, quantified recommendations. It is the diligence you run on yourself before investors run it on you.
Adversarial risk pass: An adversarial risk pass is a design step where we deliberately try to break the model we just built, documenting for each threat its likelihood, impact, mitigations, and residual risk. The residual risk is the item most analyses skip and the one that matters most to a serious investor, because a project claiming zero risk is one that has not looked.
Residual risk: Residual risk is the risk that remains after every mitigation has been applied. We state it in writing because no mitigation eliminates risk entirely, and the honest residual is the difference between a design that survives diligence and one that falls apart under the first informed question.
Depeg risk: Depeg risk is the danger that an asset-backed or pegged token loses its alignment with the asset it is meant to track. It can come from broken arbitrage, insufficient backing, a redemption run, or an oracle failure. For pegged designs it is the central risk the mechanism exists to prevent, so we model it across all of those vectors rather than assuming the peg holds.
Redemption run: A redemption run is a rush of holders redeeming a backed token at once, which can strain custody, liquidity, and operations the way a bank run strains a bank. A design that cannot service simultaneous redemptions will break its peg under stress. We size redemption capacity and reserves against a stressed scenario, not a normal day.
Investor ROI analysis: Investor ROI analysis models when each fundraising round becomes profitable across multiple price scenarios, relative to its vesting cliff. It reveals the windows where early investors are most likely to sell, which is exactly where sell-pressure clustering and cliff walls become dangerous. The healthy result is that no round turns profitable before its cliff expires.
Centralization risk: Centralization risk is the danger created when too much control sits with one party: one entity holding both mint authority and treasury deployment, a handful of operators running most validation, or insiders holding most of the supply. It is both a security risk and a credibility risk with investors. We surface every concentration of power in an admin-capability matrix and either justify it or design it out.
Monitoring framework: A monitoring framework is a post-launch set of metrics, each with a target, a warning threshold, and an action threshold, plus an escalation protocol. The metrics are derived from what the audit and simulation showed actually breaks the model, so the team watches the right numbers instead of vanity charts.

Mechanism Design Structures

The structural and legal building blocks a mechanism design document specifies. See tokenomics whitepaper for how these get synthesized for investors.

Mechanism design document (MDD): A mechanism design document is the technical backbone of a tokenomics engagement, running to a hundred-plus pages: a spec a developer can build from and an investor can evaluate. Its sections cover the asset and market thesis, entity architecture, token architecture, the core operating loop, fees, risk, and stakeholder journeys.
Entity architecture: Entity architecture is the legal and operational structure behind a token: which company controls onchain operations, which holds the assets, and how governance is shared or triggered between them. It is where bankruptcy remoteness and conflict-of-interest prevention are designed in. We recommend a structure and a separation-of-concerns table, then flag that the final form is set with the client's legal counsel.
Bankruptcy remoteness: Bankruptcy remoteness is a legal structure ensuring assets held for token holders cannot be claimed by the operating company's creditors, implemented by holding those assets in a separate asset-holding entity. Without it, token holders are unsecured creditors of the operating company; with it, the backing is legally separate from the fortunes of the issuer.
Admin-capability matrix: An admin-capability matrix is a table of every administrative power a token contract can have, including mint, burn, pause, freeze or seize, and upgrade. Each capability is a centralization risk, so each one is either justified or removed, and upgrade governance is typically specified through a multisig wallet plus a timelock.
Open-transfer model with reactive enforcement: The open-transfer model with reactive enforcement is a compliance design where tokens move freely between wallets, identity checks are enforced only at the creation and redemption gateway, and freeze functions are used reactively rather than restricting every transfer in advance. It preserves tradability and DeFi composability, which over-restrictive transfer rules can destroy.
Oracle: An oracle is the service that brings off-chain data, such as an asset's reference price, onchain for a contract to use. It is a point of trust and a point of failure, so its update cadence, deviation thresholds, and the dependency it introduces all have to be designed deliberately. For a pegged token, the oracle is part of the depeg surface, not an afterthought.
Stakeholder journey: A stakeholder journey is a narrative walkthrough of the protocol from one user archetype's point of view, from first interaction through their full lifecycle. It is how we test that the mechanism actually serves the real primary user, not the obvious one, and the same journeys carry forward into the whitepaper.

Compliance and Classification

The legal frameworks that decide which regime a token falls under, and how design choices move a token toward the lightest defensible bucket. See tokenomics design. We design toward classification outcomes; we do not give legal opinions.

Howey test: The Howey test is the US framework for determining whether an instrument is an investment contract, and therefore a security, across four prongs: an investment of money, in a common enterprise, with an expectation of profits, derived from the efforts of others. We design architectural choices that reduce a token's exposure to each prong, then hand counsel a brief of what to confirm. We do not give a legal opinion.
Security versus commodity classification: The security-versus-commodity question decides which US regime a token falls under: a security carries full disclosure and prospectus obligations, while a commodity carries lighter oversight focused on market conduct. The classification turns on what the token represents and whether holders profit from the efforts of others, not on its branding. Design consequence: for asset-backed tokens we engineer toward the commodity bucket with no token yield, no governance over the asset, redemption, and a market-set price.
MiCA: MiCA is the European Union's comprehensive framework for crypto-asset markets, which sets distinct rules for asset-referenced tokens, e-money tokens, and other crypto-assets, plus obligations on issuers and service providers. It is in active enforcement, so an EU-facing token has to know which MiCA category it lands in before launch. We map the design to its MiCA track as part of classification.
E-money token: An e-money token, in the EU framework, is a token that references a single fiat currency and functions as electronic money, carrying issuance, reserve, and redemption obligations. It sits close to the payment and stablecoin bucket and triggers some of the strictest requirements. The design question is whether the project genuinely needs to issue money or whether an existing instrument does the job.
Asset-referenced token (ART): An asset-referenced token, in the EU framework, references a basket of assets, currencies, or commodities rather than a single fiat currency, and carries its own reserve and governance obligations. It is the MiCA category many multi-asset-backed designs fall into. Knowing whether a token is an ART or an e-money token changes the obligations materially, so we classify it explicitly.
FIT-21: FIT-21 refers to US legislative efforts to draw a clearer line between which digital assets are securities and which are commodities, and to assign oversight accordingly. It matters because the security-versus-commodity boundary is the single biggest classification uncertainty for US token issuers. We design toward defensible positions that hold up regardless of where the boundary finally lands.
SAFT: A simple agreement for future tokens is an investment contract used to raise capital from accredited investors before a token exists, with tokens delivered at a later generation event. The agreement itself is typically treated as a security, even when the eventual token may not be. We design the round structure and disclosures around that reality rather than assuming the token's later classification covers the raise.
KYC / KYB: Know-your-customer and know-your-business are the identity-verification checks that confirm who a participant is before they transact. In an open-transfer compliance model, these checks are enforced at the creation and redemption gateway rather than on every transfer, which preserves tradability. Where the checks live is a design decision with direct consequences for composability.
Security-classification defense: A security-classification defense is the set of design choices that support a token's non-security position: genuine utility, no revenue distribution to holders, no passive-yield expectation, a fixed supply, and independence from the core product. It is built in from the start, not bolted on before a raise. We design it deliberately, then hand counsel the brief to confirm.

Real-World Assets (RWA)

Specialist vocabulary for bringing real assets onchain. See RWA tokenomics for the full vertical.

RWA tokenization: RWA tokenization is the process of bringing real-world assets onchain through tokens that represent ownership of or exposure to an underlying asset such as real estate, treasuries, private credit, or commodities. The asset stays in custody off-chain; the claim on it trades onchain, and enforcing that link is the whole design problem.
Proof of reserves: Proof of reserves is continuous onchain verification that publishes verified backing data for programmatic consumption, paired with a secure-mint check that blocks minting unless sufficient backing is confirmed first. The closest traditional analogy is a reserve requirement, except enforcement happens before every mint rather than in an audit after the fact.
Creation/redemption arbitrage: Creation/redemption arbitrage is the mechanism that keeps an asset-backed token aligned with its underlying spot price: arbitrageurs create new tokens when the token trades above spot plus the creation fee, and redeem when it trades below spot minus the redemption fee. It is the same structure that keeps ETF prices aligned with their net asset value, enforced in smart-contract code instead of through a fund administrator.
Arbitrage band: The arbitrage band is the price range around the underlying spot within which an asset-backed token trades, set by the width of the creation and redemption fee. A flat fee produces a symmetric, predictable band: too wide and the token aligns loosely with the asset, too narrow and nobody bothers to enforce the peg.
Custody: Custody is the safekeeping of the real-world asset that backs a token, by a qualified custodian or vault. The quality and verifiability of custody is what makes the backing real, so opaque or single-point custody is a red flag we surface immediately. The token is only as trustworthy as the custody behind it.
Procurement spread: Procurement spread is, for asset-backed tokens, an operational margin earned by sourcing the underlying asset below the quoted benchmark price, a revenue stream distinct from the disclosed user fee. It is one of the real revenue lines a revenue-first model surfaces and prices explicitly rather than blending into a single rate.
Net asset value (NAV): Net asset value is the per-token value of the underlying assets backing a token, the reference the creation and redemption mechanism keeps the market price aligned with. It is the anchor the arbitrage band forms around. A token trading persistently away from NAV signals that the arbitrage mechanism or the backing has a problem.

DePIN and GameFi

Specialist vocabulary for networks built on physical infrastructure and for token-incentivized games. See DePIN tokenomics and GameFi tokenomics.

DePIN: A decentralized physical infrastructure network uses token incentives to coordinate independent operators who supply real-world infrastructure such as compute, storage, wireless, or sensors. The token's job is to bootstrap supply before demand exists, then hand off to real usage revenue. Design consequence: we engineer the taper from incentive-funded growth to demand-funded operation, because that handoff is where most DePIN networks fail.
Two-sided market: A two-sided market connects supply and demand that each need the other to show up, such as operators and users on a DePIN network. The hard part is the cold start: neither side wants to join before the other. Tokens bootstrap the side that is the binding constraint, which is why identifying which side is already validated is the first discovery question.
DePIN bootstrapping problem: The DePIN bootstrapping problem is the cold-start challenge of attracting infrastructure operators before there is paying demand to reward them. Token emissions solve it temporarily by paying operators in tokens, but the emissions are a liability that demand has to eventually cover. The design has to plan the transition from subsidized supply to demand-funded supply before the subsidy runs out.
Operator economics: Operator economics is the profit-and-loss of running infrastructure on a DePIN network: hardware and electricity costs against token rewards and usage fees. If operators must routinely sell earned tokens to cover real costs, that selling is structural sell pressure the demand side has to absorb. We model operator economics directly because it sets both supply growth and sell pressure.
Emissions taper (DePIN): In a DePIN context, the emissions taper is the planned decline of token rewards as real usage revenue grows to replace them. Get the taper wrong and either operators leave when rewards drop or the token inflates itself into the ground. The whole design problem is matching the taper to the pace at which demand actually arrives.
GameFi tokenomics: GameFi tokenomics is the design of token economies inside games, typically pairing an inflationary reward token with a capped governance or premium token. The core risk is the death spiral, where reward emissions outrun real demand and the economy collapses once new-player inflows slow. Design consequence: we build sinks that consume reward tokens through real gameplay rather than letting emissions accumulate as pure sell pressure.
GameFi death spiral: The GameFi death spiral is the collapse that happens when a game's token rewards depend on new players buying in, and the inflows slow: the reward token's value falls, players leave, and the fall accelerates. It is the play-to-earn version of an unsustainable incentive loop. The fix is sinks that consume tokens through gameplay and rewards tied to real demand, not to recruitment.
Dual-token model: A dual-token model splits roles across two tokens, commonly an uncapped reward or utility token and a capped governance or premium token, so each can be tuned for its job. It is common in GameFi and some DePIN designs, but it only works if the two tokens stay genuinely separate. The same two-token separation rule applies: if one token's demand contaminates the other, the structure has failed its purpose.

Economic Simulation

The modeling vocabulary for proving a token economy holds across thousands of scenarios. Available inside the Data Room.

Monte Carlo simulation: A Monte Carlo simulation is a stress-testing framework that runs roughly a thousand independent multi-year paths, each with its own randomized price trajectory, growth path, and user composition, producing a probability distribution of outcomes rather than a single forecast. It exists to find where a model breaks, not to predict a price.
Coverage ratio: Coverage ratio is cumulative revenue divided by cumulative cost, the primary viability metric in a fee-versus-cost simulation. Above 1.0 means revenue exceeds cost; reading it across percentiles, not just at the median, shows how often the model is underwater.
Geometric Brownian motion (GBM): Geometric Brownian motion is the standard stochastic process for modeling asset and commodity prices in a simulation, parameterized by a drift and a volatility. It is what generates each path's randomized price trajectory.
Cohort-based survival model: A cohort-based survival model represents users as monthly cohorts that decay over time, with multiple archetypes that hold for different average periods and route redemptions differently, rather than assuming a single flat churn rate. It captures the reality that a long-term holder and a yield tourist behave nothing alike.
Markov-chain market model: A Markov-chain market model represents the market state, such as loose, normal, or tight conditions, as a state machine with transition probabilities, optionally correlated to price moves. It adds the realism that conditions persist and shift rather than resetting randomly each month. It feeds the behavioral side of the simulation, such as accelerated redemptions during a downturn.
Sensitivity analysis: Sensitivity analysis sweeps the key inputs across ranges to find which variable moves the outcome most and where the cliffs are. It is how the simulation points the team to the single variable that moves the outcome most. A two-dimensional sweep often reveals a boundary, such as a user-mix-versus-fee line, that no single-variable view would show.
Front-loaded business model: A front-loaded business model is one where early surpluses fund later deficits, which is why a high monthly-deficit frequency can coexist with cumulative profitability. Recognizing this prevents a simulation from being read as a failure when it is actually solvent over the full horizon.
Revenue model: A revenue model is the deterministic, multi-scenario financial model that the Monte Carlo simulation stress-tests, with every revenue stream modeled explicitly per line of business rather than as a blended rate. One scenario switch flips it between conservative, base, and aggressive cases. It is the base case the stochastic simulation perturbs across a thousand paths.

Frequently Asked Questions

The most-searched tokenomics terms, answered first.

What is token allocation?: Token allocation is the division of total token supply across stakeholder buckets such as community, team, investors, treasury, and liquidity. A complete allocation design is a table where every bucket carries a percentage, a token count, a vesting cliff, a vesting length, and a launch-day unlock, all summing to 100%. The balance between community and insiders is the first signal a serious investor reads, because a model that over-allocates to insiders tends to dump on the people it needed to keep.
What is the difference between FDV and market cap?: Fully-diluted valuation is the token price multiplied by the maximum or total supply, while market cap is the price multiplied by the circulating supply only. FDV counts the tokens still locked in vesting, so it shows the real sticker price; market cap shows what is in the market today. A low market cap sitting under a much larger FDV is a warning that future unlocks will weigh on the price.
What is a TGE?: A token generation event is the moment a token is first created and begins to exist and trade. It is the launch line everything before it builds toward and everything after it lives with, because most errors baked in at the TGE are permanent. We stress-test the float and liquidity before the TGE rather than discovering the problems live.
What is a vesting cliff?: A vesting cliff is a period after a token launch during which an allocation bucket is fully locked and nothing unlocks, followed by the point where vesting begins. Cliffs exist to stop early investors and team members from selling on day one. The risk is a cliff wall, where several buckets end their cliffs in the same month and concentrate sell pressure into a single window, which is one of the most common preventable causes of a post-launch price collapse.
What is the difference between staking and restaking?: Staking is locking tokens to secure a single proof-of-stake network or qualify for rewards, with slashing risk tied to that one network. Restaking reuses already-staked collateral to secure additional services beyond the base chain, earning extra fees in exchange for taking on extra slashing exposure. The same capital backs multiple obligations at once, which is the source of both the higher yield and the correlated risk a restaking design has to reserve against.
What is a tokenomics audit?: A tokenomics audit is an independent, third-party review of a token's economic model that finds the risks capable of breaking it before a raise or launch. A real audit runs more than a dozen distinct quantitative analyses covering vesting, liquidity, investor ROI, and mechanism design, each with its own severity-rated risk table, and ends in a verdict with prioritized recommendations. It is the diligence you run on yourself before investors run it on you.
What is the difference between a utility token and a security token?: A utility token is consumed inside a product to access a service or pay a fee, so its demand tracks usage and it triggers a light regulatory regime. A security token represents a claim on profits, revenue, or a managed return, so holders expect to profit from the efforts of others, which triggers full securities law including prospectus and disclosure obligations. The classification is determined by what the token does and the rights it carries, not by what it is called in the marketing.
What is the Howey test?: The Howey test is the US framework for deciding whether an instrument is an investment contract, and therefore a security, across four prongs: an investment of money, in a common enterprise, with an expectation of profits, derived from the efforts of others. A token that satisfies all four prongs is likely a security. We design architectural choices that reduce a token's exposure to each prong, then hand counsel a brief of what to confirm, rather than giving a legal opinion ourselves.

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.

Book a discovery call

80+ projects advised. Complete tokenomics in 4 to 6 weeks.