A tokenomics review is not a verdict and does not tell you what a token is worth. It is a list of things you can look up, and its whole value is that it stops you skipping the item you were going to skip. What follows is that list: six passes over supply, distribution, revenue, treasury and governance, each written as what to check, where the original lives, and what a bad answer looks like. It is the input list a token valuation framework needs, not the framework itself, and finishing it is not an investment judgement.
Supply and unlocks: what to write down first
Write down four numbers with a date beside each: maximum supply, total supply, circulating supply, and how much unlocks over the next twelve and twenty-four months. Express the unlocks as a share of what already circulates, not as a token count. A token count means nothing without the float it lands on.
Take the first three from the token contract, not from a dashboard. Standard token contracts publish total supply and any address balance as public read functions, and every transfer, including the mint that created the supply, is logged as an event. A dashboard inherits whatever the project submitted to it; the contract does not. The unlock figures come from the lockup and vesting contracts where they exist and from the project's documents where they do not, and the difference between those two cases is itself a finding.
Reading a cliff means finding the flat stretch and measuring the step at its end. Note the date, the size of the step against circulating supply on that date, and whether the step belongs to one recipient or to several hundred. The same step means different things in those two cases, and usually only the first number is published.
The red flags are cheap to spot. No schedule. A schedule published as a picture with no contract enforcing it. A circulating-supply figure that will not reconcile with the balances you can read yourself. And tokens the documentation still calls locked sitting in an ordinary address that could move them today.
Allocation and concentration: who holds it, and for how long
The allocation question is what share went to the team and early backers, what share to the treasury or foundation, what share to users, and how long each is committed for. The intended split is stated only in the project's own documents, so read them, then stop trusting them and go and find the addresses.
Verification is possible because balances and transfers are public. The claim that insider tokens are locked becomes a concrete check: are they in a contract that releases them on a schedule, or in an ordinary wallet with a promise attached? A vesting contract exposes its start, duration, end and currently releasable amount, so the schedule can be read instead of believed.
One caveat applies to everything addresses tell you. Address counts overstate dispersion in one direction and understate it in the other: one holder can spread across many addresses, and one exchange address can hold the balances of thousands. Treat a top-holder list as a ceiling on concentration, not a measurement of it, and never as a headcount.
The red flag most often missed sits inside the lock. A widely used vesting contract is owned by its beneficiary and that ownership can be transferred, so the right to receive unvested tokens can be sold even though the tokens never move. A lock that can change hands is a schedule, not a guarantee, and whether a given deployment allows it is something to check rather than assume.
Revenue and value capture: where the money goes
Two separate questions live here, and merging them is the most common error in the exercise. First, does the protocol take money from anyone: what the fee is, what it was charged on last quarter, in which asset it arrived and into which address. Second, does any of that money reach the token.
Answer the first from the fee parameters in the contracts and the inflows to the receiving address. Watch what a marketing page counts: gross value moving through a protocol is not what the protocol keeps, and the two often differ by an order of magnitude. You want the number that arrives somewhere and stays.
Answer the second by finding the mechanism and checking whether it is switched on. Read the parameter, not the roadmap. If the documents describe value reaching holders in the conditional tense, the honest entry is that today there is none, with a note of what would have to change and who would have to do it.
A red flag: revenue arriving at an address controlled by the same people who control supply, with no written rule about what happens next. Discretion is not a mechanism, and the absence of a rule is the finding.
Treasury runway: how many months the spending can continue
Protocol treasury runway needs three numbers: the total value of the treasury, how much of it is the project's own token, and the monthly spend. Then do the division that matters, spending divided into the part that is not the project's own token, because that is the runway that holds without anyone selling.
Take a treasury worth 600: 240 of the project's own tokens at a price of 2, which is 480, plus 120 in stable assets. Monthly spend is 20 and goes out in stable assets, because salaries, audits and servers do. The headline runway is 600 divided by 20, or 30 months. The runway that requires nobody to sell is 120 divided by 20, or 6 months. Both are true, and they are five times apart.
Now halve the token price to 1. The token holding is worth 240, the treasury 360, and the headline runway falls from 30 months to 18. That is the first effect. The second is worse: refilling the stable buffer to a year of spending, which is 240, now takes 120 of value, and at a price of 1 that is 120 tokens where at 2 it was 60. The treasury shrinks and the sale needed to refill it doubles, and the second happens because of the first.
This is why some organisations publish the buffer as a policy. One large ecosystem foundation states its targets as annual operating expenses of 15% of the treasury and 2.5 years of that spending held in reserves denominated outside its own asset, and says the gap between actual reserves and that buffer determines how much of its native asset is sold over the next three months. Whether the numbers suit you is separate; the shape is the point, because a buffer decided in advance means the selling is not decided during a drawdown.
Red flags: a runway quoted on the full treasury with no split; no published monthly spend; undisclosed treasury addresses, which make every other number here unverifiable.
Governance and mutability: who can change the rules
Everything above describes rules that hold today. This section asks how quickly they could be different. List the parameters that would change your view if they moved, such as the supply cap, mint permission, fee rates and the vesting schedules, then find who holds the right to move each one.
The answers are readable. Access-control roles are recorded in the contracts. A timelock enforces a minimum delay between a change being scheduled and executed, and that minimum is a public read; each scheduling is logged, and a separate role can cancel one still pending. A multisig publishes its owner list and the threshold needed to execute, and emits an event whenever either changes.
Read the delay against what it is delaying. A timelock protects you only if you would notice inside it and could act. Two days is long for someone watching a monitoring feed and short for everybody else. Ask the same of the threshold: three signatures out of five means little if the five signers are five laptops on one desk, and there is no on-chain answer to that.
The red flags: mint permission on an address behind neither a timelock nor a multisig; a threshold of one; a timelock whose own delay can be shortened by the body it is meant to constrain. Any of them means the numbers from the earlier sections have an expiry date you do not control.
Residual uncertainty: what the checklist still cannot tell you
None of this is an investment judgement. The list is a completeness device: it shrinks the set of things you did not check. You can complete every item, get every number right and still be wrong, because supply, rules and treasuries are the sell side of the question and the list says nothing about who wants to buy.
Every answer is a snapshot with a date. Schedules get amended, parameters get changed by exactly the process in the previous section, treasuries get reallocated. Write the date beside each number as you record it, and treat anything older than a quarter as a hypothesis.
Disclosure quality varies with where the offer was made. In some jurisdictions the content of a public offering document is prescribed by law, which requires the information to be fair, clear and not misleading and forbids claims about future value; in others nothing is required. Neither settles the matter. A prescribed document is not verification of the numbers in it, and a missing one is not proof of a problem.
Then there is intent, which never resolves. Nothing on-chain tells you what people will do with the powers they legitimately hold, or whether an amendable schedule will be amended. The checklist narrows the range of surprises. It does not remove them, and treating a completed checklist as a conclusion is how a careful process turns back into a guess.
The bottom line
Work the six passes in order and record each answer with its date: supply and unlocks as a share of the float, allocation and where the tokens actually sit, revenue and whether a live mechanism carries it to the token, treasury runway measured on the non-native part alone, and who can change the parameters and how fast. Read the primary sources, meaning the contracts, the addresses and the project's own documents, rather than a summary of them, and let each section's red flags stand as findings in their own right. What you end up with is a fuller picture and a shorter list of things you have not looked at. It is not a valuation and not an investment judgement, and the moment it starts to feel like one, that is the next item to check.
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of August 2026; refer to the latest official information.
References
[1] ERC-20: Token Standard (EIP-20) eips.ethereum.org
[2] OpenZeppelin Contracts 5.x - Finance: VestingWallet and VestingWalletCliff docs.openzeppelin.com
[3] OpenZeppelin Contracts 5.x - Governance: TimelockController docs.openzeppelin.com
[4] Safe Docs - How do Safe Smart Accounts work? Owner management and threshold docs.safe.global
[5] Ethereum Foundation Treasury Policy - annual opex and years of opex buffer blog.ethereum.org
[6] Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA), Article 6 eur-lex.europa.eu
