Before TGE, an outside reviewer should test whether the tokenomics design that was approved is the one the contracts will actually execute, and whether the unlock calendar can survive the market. The stakes are measurable. Keyrock’s study of more than 16,000 unlock events across 40 tokens found that about 90% put negative pressure on price.
Who decides this
The foundation council owns the token model, and the CFO owns the numbers behind it. The council is accountable for the allocation and the promises made to holders. The CFO is accountable for treasury runway, the market-maker and exchange commitments, and the reconciliation between the published model and what is deployed on-chain. A tokenomics review should report to both, not to the team that designed the model.
What should the review compare: the spreadsheet or the contracts?
The review should start from the deployed contracts and work back to the spreadsheet, because holders and exchanges will see the contracts. Most models are reviewed as documents. The failure is usually in the gap between the document and the code.
An outside reviewer reconciles four sources line by line: the allocation table in the token paper, the signed investor and team agreements, the vesting and lock contracts, and the wallet addresses that hold each bucket. Every percentage should match across all four. Every cliff, duration and release frequency should match. Every bucket should sit in a contract or a named, disclosed wallet, not in a team multisig with no schedule.
This is where on-chain vesting earns its cost. A schedule enforced by a token vesting contract can be checked by anyone. A schedule promised in a PDF can only be trusted.
The checklist an outside reviewer runs
A pre-TGE token model review covers seven areas, and each one has a specific failure the reviewer is looking for. The table sets out what is checked, the evidence requested, and the red flag that should stop the launch until it is fixed.
| Area | What the reviewer checks | Evidence requested | Red flag |
|---|---|---|---|
| Allocation | Each bucket’s share, recipient and purpose | Allocation table, cap table, signed SAFTs and grants | Totals that do not reconcile, or a bucket with no stated purpose |
| Vesting vs on-chain contracts | Cliffs, durations and release cadence as deployed | Contract addresses and parameters | Any bucket vesting off-chain, or parameters that differ from the paper |
| Unlock overhang | Tokens unlocking each month against expected liquidity | Month-by-month unlock calendar for 36 months | Team and investor cliffs landing in the same month |
| Emissions | Rewards, staking and incentive issuance | Emission schedule and the budget owner | Open-ended emissions with no cap or review date |
| Float at TGE vs FDV | Circulating supply and implied fully diluted value at listing | Circulating supply calculation and listing price assumptions | A small float priced at a valuation the circulating supply cannot support |
| Market-maker loans | Loan size, term, strikes, return terms and reporting | Draft market-maker agreements | A single strike, a term longer than the liquidity need, no reporting |
| Exchange allocation | Tokens committed to listings, launch programmes or campaigns | Exchange term sheets | Commitments outside the published allocation |
The reviewer should deliver a written finding on each row, not a score. The council needs to know which rows block the launch and which can be fixed after it.
Two rows are routinely skipped because they sit outside the token paper. Emissions are often set by the product team as staking or incentive parameters, so they never reach the council as supply decisions. The reviewer should add every emission source to the unlock calendar and name the person who can change it. Exchange allocations are usually agreed late, in term sheets the CFO sees and the council does not. The reviewer should trace each commitment to a bucket in the published allocation, or require one to be created and disclosed before listing.
How much of the unlock calendar can the market absorb?
The unlock calendar should be judged by who receives each release and when, not only by size. Keyrock’s analysis found price impact often begins about 30 days before an unlock, as holders position ahead of it. Team unlocks were the most damaging category, with drops of about 25%. Ecosystem development unlocks averaged a small positive effect.
That gives the reviewer three practical tests. First, separate team cliffs from investor cliffs so they never land in the same month. Second, prefer linear release after a cliff, since Keyrock found linear unlocks cause less short-term disruption than initial cliffs. Third, model the 30 days before each large unlock as a period of pressure, and make sure treasury, market-making and communications plans cover it.
The aggregate picture explains why exchanges and investors now ask about this. Binance Research estimated in May 2024 that about $155 billion in tokens would unlock between 2024 and 2030, and warned this could mean selling pressure unless demand rose to match. A reviewer cannot change that market. It can make sure the organization’s own calendar is not part of the problem.
Is the float at TGE consistent with the valuation?
The float at TGE should be large enough that the listing price reflects real trading, not a thin market priced off a headline valuation. Binance Research’s same report described a trend of tokens launching with low circulating supply and high fully diluted valuations. It urged project teams to weigh the long-term effects of tokenomics design, and said venture investors could work with teams toward fairer supply distribution and reasonable valuations.
There is no market standard for the right float, and any reviewer who quotes one is guessing. The useful test is internal consistency. Take the circulating supply at TGE, the expected listing price and the unlock calendar for the first twelve months. Then ask how much new supply arrives for every token that trades on day one. If the answer is several times the launch float, the council should know before listing, not after.
What should the reviewer look for in market-maker terms?
The reviewer should treat market-maker agreements as part of the token model, because loaned tokens are supply. In the common loan-and-option structure, the project lends tokens and the market maker can later buy them at agreed strike prices. Arrakis describes typical loans of 1–5% of supply for 12–24 months, with options in several strike tranches and no upfront cash.
The risks are specific. A market maker given only tokens may sell some to fund the bid side, adding supply during price discovery. Tokenomist’s guidance on loan-and-call-option terms flags a single low strike, a term longer than the liquidity need and an unscheduled return of unexercised tokens. It recommends a ladder of strikes, option coverage well below the full loan, and measurable spread, depth and uptime obligations. Arrakis adds that projects typically use two or three market makers to avoid depending on one.
We would add one rule. Every token loaned to a market maker should appear in the published allocation and the circulating supply calculation. If it is not there, the float figure the council publishes is wrong.
What goes wrong: tokenomics the contractor rewrote
The council approves a model. A development contractor then deploys it, and somewhere between the spreadsheet and the code the model changes.
The changes are rarely malicious. A cliff is entered in days instead of months. A vesting contract is skipped for one bucket because the investor wanted tokens at TGE. A market-maker loan is sent from the ecosystem wallet without being added to the allocation. An exchange campaign draws from treasury. Each change was small and made by someone trying to hit a launch date. Together they mean the token that lists is not the token the council approved, and the first person to notice is an on-chain analyst.
The defence is sequence and authority. The outside review happens after deployment to testnet and before TGE. The reviewer has authority to block the launch on a reconciliation failure. Any change to deployed parameters after the review goes back to the council in writing.
How Alcyone approaches it
Alcyone treats the token model as something built and verified, not only designed. In how an Alcyone token economics engagement runs, the design phase produces a plan covering vesting and lock structure and a named owner for every part. The build phase implements token creation, locks and vesting with the client’s engineers and vendors and ends with a launch-readiness review alongside audit partners. Market-maker contracts are reviewed as part of the launch phase. The partners behind Alcyone built and operate Team Finance, which Alcyone reports holds vesting and lock schedules for more than 40,000 projects, though clients are under no obligation to use it.