AI-generated tokenomics drafts usually fail in the same place. The narrative looks coherent. The parameter surface does not. Allocations can be directionally plausible and still be wrong for the project stage. Vesting can look clean cohort by cohort and still create a synchronized sell wall. A sink can sound deflationary and still leave net supply inflationary in every realistic scenario. Pre-launch review is not about whether the deck reads well. It is about whether the mechanism survives contact with capital, governance, and regulation.
This is a pre-flight checklist for teams that already have a draft. Most of these are audit tasks, not design tasks. The goal is simple: identify the parts of the token economy that will break first, before the market does it for you.
Use a red-flag count, not a vibes check
A launch review should produce a small number of binary outputs. Each item below should end in green, amber, or red. If more than two items are red, the tokenomics is not launch-ready.
| Check | What to look for | What a red flag looks like | Self-verifiable or needs an economist |
|---|---|---|---|
| 1. Allocation sanity check | Does the split between team, investors, treasury, community, ecosystem, and liquidity match the project type and stage? An infrastructure protocol, an application token, and an AI-agent network do not need the same balance sheet. | Large “community” or “ecosystem” buckets with no credible deployment path, a treasury too small for runway, or insider ownership that dominates future float even after vesting. | Mostly self-verifiable if the cap table and treasury plan exist. Benchmarking against comparable launches usually needs an economist. |
| 2. Vesting collision analysis | Merge every cohort into one unlock calendar. Team, investors, advisors, foundation, grants, staking, market makers, and ecosystem incentives must be viewed on one timeline. | Two or more major cohorts unlocking in the same month, especially if that month also carries exchange listings, market maker inventory releases, or rewards emissions. | The calendar merge is self-verifiable. The absorption analysis usually needs an economist. |
| 3. Emission curve pressure test | Compare gross issuance and net circulating supply growth against realistic demand, not forecasted excitement. Model weak, base, and strong adoption cases. | The token only clears if users, TVL, or fees grow at heroic rates. APR is doing the distribution job because product demand is not. | Basic issuance math is self-verifiable. Demand modeling usually needs an economist. |
| 4. Utility statement vs MiCA “exclusively” test | Read the whitepaper, token page, investor deck, exchange materials, and community messaging together. The token’s stated purpose must not conflict across documents. | The paper says “utility,” but the market story leans on governance, appreciation, fee-linked upside, or treasury intervention to sustain value. | Obvious inconsistencies are self-verifiable. A serious review needs legal counsel and a token economist. |
| 5. Sink mechanism review | Write the net supply equation explicitly. Burns, buybacks, staking locks, collateral locks, fees, and reward offsets must be quantified under realistic usage. | The sink is discretionary, depends on extreme volume assumptions, or burns less than issuance in every plausible operating case. | Arithmetic is self-verifiable. Scenario design usually needs an economist. |
| 6. Governance parameter check | List every authority that can change emissions, fees, treasury transfers, liquidity rules, role assignments, or emergency powers. Then map thresholds, delays, and bounds. | A multisig can change economic parameters immediately, admin roles are circular, or “temporary” emergency powers have no sunset. | Contract roles and docs are self-verifiable. Complex control surfaces need economist and security review. |
| 7. TGE liquidity provisioning plan | Define venue, depth, range width, initial inventory, market maker obligations, treasury reserves, and the first two weeks of post-TGE operations. | There is a listing plan but no actual liquidity plan, or the initial pool is so thin that the first seller resets the chart. | Partly self-verifiable. Market microstructure design usually needs an economist or experienced launch operator. |
| 8. Cliff timing vs market cycle exposure | Map every major unlock against expected product milestones, sector cycles, likely listing windows, and broader market liquidity. | The first large cliff lands into a thin market, right after a marketing peak, or before the product can create organic token demand. | The date map is self-verifiable. Probabilistic cycle exposure is better handled by an economist. |
Allocation sanity check and vesting collisions are the first place to audit
Allocation quality is less about ideology than operational fit. A token economy for a pre-product AI application should not look like a mature L1 treasury model. If a draft allocates huge reserves to “ecosystem incentives” before the project has a measurable distribution engine, that bucket is not strategy. It is deferred dilution. The right question is not whether an allocation looks common. The right question is whether that allocation can be deployed credibly by this team, at this stage, with this business model.
Vesting collisions matter more than individual vesting schedules. A team cliff, an investor cliff, and a rewards ramp can each look reasonable in isolation. Combined, they can create a single quarter where float expands faster than demand can absorb it. Build a monthly or weekly waterfall of new liquid supply for at least 24 months. Do not stop at “team 24-month vesting” and “investors 12-month cliff.” Aggregate everything.
Do not trust the PDF alone. Vesting implementation details can diverge from the schedule presented to the market. OpenZeppelin’s VestingWallet documentation notes that assets transferred after vesting starts may become partly immediately releasable, and that ownership transfer means unvested claims can in practice be sold.
A cliff is not just a date. A cliff is a scheduled liquidity event. The correct review question is not “when do tokens unlock?” It is “who receives liquid inventory at that date, what is their cost basis, and what venue depth exists when they receive it?” Low-cost insiders unlocking into shallow post-TGE markets create a deterministic pressure point. If that date also follows a listing or a strong marketing cycle, the setup is worse, not better.
Cliff timing should therefore be reviewed against market-cycle exposure, not only against internal roadmaps. If the first major insider unlock arrives before product usage, fee generation, or sticky staking behavior is established, then price support depends on narrative persistence. That is not a mechanism. That is hope.
Emission curves fail when demand is narrated instead of modeled
An emission curve is acceptable only if realistic demand can absorb it. The minimum model is simple. Project token issuance by month. Project likely liquid float by month. Then compare net new sellable supply against realistic sources of buy-side demand: required utility consumption, collateral demand, staking with genuine lock-in, treasury accumulation by third parties, or market-making inventory that must be replenished. If none of those exist at meaningful scale, emissions are just future overhang with a dashboard attached.
APR is not demand. Subsidized staking can reduce immediately tradable float, but only if the lock mechanics are meaningful and the reward source is sustainable. If emissions are funding the headline yield while the token has weak native demand, the design is distributing inventory to people who are being paid to wait for an exit. That is a temporary float delay, not durable equilibrium.
A sink is only deflationary if it exceeds issuance under realized usage. The cleanest public example is Ethereum’s EIP-1559 logic: the protocol burns the base fee, but the specification is explicit that ETH is deflationary only if more is burned than issued; otherwise it remains inflationary.
That arithmetic should be copied into your own review. Write the net supply identity in one line: new issuance minus burns minus permanently locked supply plus any reintroduced supply. If the “deflationary” story depends on discretionary buybacks, emergency treasury action, or volumes that sit far above the base case, then the sink is marketing language, not mechanism design.
Red flags here are easy to spot. Burns that only activate at unrealistic volume thresholds. Buybacks funded by fees that do not yet exist. Lockups that can be reversed quickly through governance. Reward schedules that ramp before utility is live. Any one of those can be survivable. Three of them in one design usually means the draft was optimized for plausibility, not for equilibrium.
The MiCA utility test is stricter than most token decks imply
MiCA matters even for teams not launching in the EU because it forces a more disciplined utility claim. Since December 30, 2024, MiCA applies fully, and its core utility token definition in Article 3(1)(9) is narrow: a utility token is a crypto-asset intended only to provide access to a good or service supplied by its issuer.
The word that matters in practice is exclusively. Your review should test whether the token story can survive that constraint. If the same token is presented as access, governance, economic upside, fee-linked value capture, treasury-backed support, and exchange-traded speculation, the utility-only framing is structurally weak. This is not solved by changing one sentence in the whitepaper. It is solved by aligning the full rights bundle and the full communications bundle.
MiCA also draws a line around operational reality. The regulation includes an exemption where the offer concerns a utility token providing access to a good or service that exists or is in operation, and where the good or service does not yet exist, the public offer described in the whitepaper may not exceed 12 months from publication.
For pre-launch review, the implication is mechanical. Put the utility statement next to the actual token rights. Then put both next to product status. If access is promised but the service is not operational, the timeline matters. If utility is promised but governance or economic value capture is doing the real work, the classification story is internally unstable. This is one of the few checklist items where a team can self-detect obvious inconsistencies but should not self-certify the final answer.
Governance parameters are tokenomics parameters
Governance is not a separate layer from tokenomics. Governance defines who may change tokenomics after launch. A design that looks deterministic on paper but allows a multisig to rewrite emissions, treasury flows, reward rates, or liquidity rules at will is not rule-based. It is discretionary economic policy with a token attached.
There is a useful benchmark in live governance design. Compound’s governance documentation exposes proposal threshold and quorum, voting delay, voting period, and timelock as explicit parameters. In the current v2 docs, an address needs 25,000 delegated COMP to create a proposal, voting starts after a 2-day review period, voting lasts 3 days, successful proposals require at least 400,000 votes cast in support, and execution is delayed by a 2-day timelock.
The numbers are not universal. The design lesson is. Good governance makes the economic control surface inspectable. Reviewers should therefore list every parameter that can affect float, yield, fee routing, treasury deployment, or emergency intervention. Then ask four questions. Who can change it. Under what threshold. With what delay. Inside what bounds.
Role systems need the same treatment. OpenZeppelin’s access-control documentation states that each role has an associated admin role, and that the default admin role can grant and revoke other roles while also being its own admin unless the design adds extra constraints.
That is a direct tokenomics concern. If the same actor can mint, redirect rewards, reassign admins, pause transfers, or move treasury assets without meaningful delay, the market is underwriting governance risk as part of token value. Teams often describe this as flexibility. Mechanism designers should call it what it is: a mutable policy surface. Sometimes that trade-off is justified. It should never be hidden.
TGE liquidity provisioning decides whether the first price is information or noise
The TGE liquidity plan is part of the token economy, not a later exchange-ops task. It sits inside the broader work required to launch a token. Your draft should specify where liquidity appears, who provides it, how wide the ranges are, what inventory is committed, what slippage is acceptable, and what happens when the first large seller hits the book. If these answers are missing, the launch price is mostly a function of thin depth and timing advantage.
Uniswap’s current developer documentation is explicit that providing liquidity in v3 and v4 is concentrated. LPs choose a specific price range, which improves capital efficiency but requires active management.
That has a practical implication for TGE review. A treasury that says “we will seed a DEX pool” has not said enough. On concentrated-liquidity venues, range selection is a price-policy decision. Too narrow and the pool gets exhausted immediately. Too wide and capital efficiency collapses. If no one owns the post-TGE rebalancing process, your “liquidity” is just an opening gesture.
Modern launch mechanisms make this even clearer. Uniswap’s Liquidity Launchpad framework uses a Continuous Clearing Auction to discover price and then seeds a v4 pool at the discovered price.
Balancer’s Liquidity Bootstrapping Pools provide another formalized example. LBPs dynamically change token weights over time, can begin at intentionally high prices, and are designed to let price descend toward market equilibrium while reducing the amount of starting quote-asset capital needed versus a standard 50/50 pool.
The review standard is straightforward. If the token needs a large amount of immediate secondary-market demand just to survive first contact, the tokenomics is too brittle. Good TGE liquidity design assumes imperfect demand, adversarial timing, and early volatility. It does not assume a clean upward path because the community is aligned.
Cliff timing belongs in the same section because liquidity and unlocks interact. A well-timed cliff into deep, rule-governed liquidity can be manageable. The same cliff into thin liquidity, wide spreads, and unclear market-maker obligations becomes a forced price-discovery event. That is exactly why vesting review and TGE review should be performed together.
The launch decision is simple even when the model is not
Most pre-launch token reviews do not fail because the math is impossible. They fail because no one forces the draft into one integrated system view. Allocation is reviewed without treasury runway. Vesting is reviewed without liquidity depth. Emissions are reviewed without demand realism. Utility language is reviewed without reading the rest of the rights bundle. Governance is reviewed as “ops.” It is all one set of token economy design components.
At FinDaS Tokenomics, the useful pre-launch review is the one that collapses the whole draft into a few hard surfaces: who gets liquid supply when, what net issuance looks like under weak demand, which actors can change economic parameters, what the token is actually for, and whether the market structure at TGE can absorb the first real sellers. That is token economy design in its audit form.
If more than two items flag red, the tokenomics is not launch-ready, and closing that gap is what a token economist is actually hired to do. If outside help is needed, watch for hiring red flags before outsourcing the review.
