Trackers, exchanges and serious buyers all read the same page, and they all reject it for the same reason: the numbers on it cannot be reconciled with the chain. Knowing how to prepare a tokenomics page starts with one point: it is not a design exercise. It is a set of claims that someone will check against a block explorer within about four minutes.
This is how to prepare a tokenomics page that survives that check, and what each element is actually there to prove.
1. How to prepare a tokenomics page: start from the contract, not the pitch deck
Pull total supply from the contract itself, not from an internal document. If the contract is mintable, say so on the page and name who holds the minting rights. If supply was changed after launch, the page should reflect the current state and not the original plan.
A page whose headline supply figure differs from the explorer fails immediately, and reviewers do not usually write back to ask which number is right.
2. Define circulating supply and show your working
Circulating supply is total supply minus everything that cannot move: locked contracts, unvested team and investor allocations, treasury holdings not yet deployed, and burned tokens sent to a provably unspendable address.
Publish the subtraction rather than the result. Every exclusion needs an address a reader can open. Tokens held in a plain wallet the team controls are circulating, whatever the internal policy says about not selling them, and trackers apply that rule strictly.
3. Publish the allocation table with addresses
Break the supply into its buckets: team, investors, treasury, ecosystem and incentives, public sale, liquidity. Give each bucket a percentage, an absolute number, and the address holding it.
The addresses are the part that matters. A pie chart without them is a picture. With them, a reader can confirm the buckets add up to total supply and check that the team allocation is where it claims to be, which is exactly what an exchange reviewer does.
4. Give the vesting schedule as dates and amounts
For each locked bucket, state the cliff, the vesting period, the release frequency and the amount released each time. A reader should be able to work out, without asking, how many tokens enter circulation in any given month for the next two years.
Where vesting is enforced by a contract, link it. Where it is a promise in a document, say that plainly. The difference is large and pretending it does not exist is the fastest way to lose a reviewer’s trust.
5. Explain what the token is for
State the mechanism in one paragraph: what holding the token lets someone do, where demand for it comes from, and what happens to the fees or emissions the system produces. Utility that only exists in a future roadmap phase should be labelled as such.
This section is short in good tokenomics pages and long in bad ones. Length here usually signals that the mechanism is being described in place of being demonstrated.
6. Show emissions and burns as a net figure
If the protocol emits tokens as rewards, give the current rate and the schedule for changing it. If it burns tokens, give the mechanism and the actual amount burned to date, with transactions.
Then state the net effect. A deflationary claim alongside an emissions schedule that outpaces the burn is checkable arithmetic, and someone will do it publicly at the least convenient moment.
7. Match the page to every external listing
The figures on your page, on the trackers, in exchange applications and in the whitepaper have to agree exactly. Trackers cross-check against the contract and against each other, and a mismatch stalls an application while someone works out which source is authoritative.
Keep one internal document as the source of truth and update every surface from it. The tracker submission process, including the supply fields they verify, is covered in how to get listed on CoinGecko and CoinMarketCap.
8. Date the page and keep it current
Put a last-updated date at the top and change it when the numbers change. Circulating supply moves every time a tranche unlocks, and a page that still shows launch figures a year later tells a reader the project is not paying attention to its own token.
Set a calendar reminder for each unlock date. The update takes ten minutes and the alternative is being corrected in public by someone reading the explorer.
Who owns the page inside the team
Assign one person and record the name in the internal document rather than on the page itself. Tokenomics touches finance, legal and engineering, and a page with no owner drifts within weeks because each team assumes another one updated it. The owner does not need to write the copy. They need the authority to ask the contract deployer for an address and get an answer the same day, and the calendar access to schedule the reviews that keep the figures honest.
Give that person read access to the treasury multisig and the vesting contracts so figures can be confirmed without calling a meeting. Where a foundation and an operating company both hold allocations, write down which entity each address belongs to before publishing. Readers ask that question constantly, and a page that cannot answer it quickly gets described as opaque however accurate the numbers are.
How to prepare a tokenomics page under deadline
Exchange applications and listing windows arrive with short notice, and the page is usually the last artefact anyone remembers. Working backwards, the slow parts are collecting addresses and getting legal sign-off on how allocations are described. Start both on the first day and write the prose while you wait. An allocation table with placeholder addresses can be built in an hour; getting the real addresses confirmed by whoever controls them takes days.
If something cannot be confirmed in time, publish the page without that row and mark it as pending with a date. A missing row a reviewer can see is survivable. A row carrying a number nobody inside the team can source is the failure that costs the application, because the reviewer’s next question goes unanswered while the window closes.
What to publish when custody is messy
Real allocations rarely sit in a tidy set of labelled wallets. Tokens move between a deployer address, a multisig and an exchange account during setup, and the explorer keeps every hop. Rather than hiding the trail, describe it: state which address currently holds each bucket, name the previous holder where the transfer is recent, and link the transaction. Readers who find a large transfer you did not mention will assume the worst available explanation for it.
For allocations held with a custodian or an exchange, say so and give the address if the custodian publishes one. Where no address exists, write the sentence plainly: the bucket is held off-chain by a named party under a named arrangement. An honest gap is checkable in the sense that matters. An address pointing at a wallet whose contents contradict the table is not.
Handling a supply change after launch
Supply changes for ordinary reasons: a migration to a new contract, a burn agreed by governance, an additional mint approved for a treasury round. Each of those breaks every figure on the page at once, so treat the change as a publishing task rather than a footnote. Update the headline supply, the circulating calculation, the allocation table and the net emissions statement in the same edit, then change the date at the top.
Keep the previous version reachable with a short note on what changed and why. Trackers and reviewers who indexed the old figures will notice the difference, and a visible history answers the question before anyone asks it. Quietly editing a number that external sites have already copied produces exactly the mismatch the page exists to prevent, and it produces it in the places you do not control.
The questions reviewers send back
The follow-ups are predictable. Which address holds the team allocation and who signs for it. Why the circulating figure differs from the one on a tracker. What enforces the vesting. Whether the contract can still mint. Whether the liquidity is locked and until when. Draft answers to all of those before submitting anything, and keep them beside the source document so any team member can reply without a round of internal checking first.
Reply with addresses and transaction hashes rather than prose. A reviewer working through a queue accepts a link they can open and stalls on a paragraph explaining why a discrepancy is immaterial. If a figure genuinely changed between submission and review, say when it changed and give the transaction that changed it, rather than restating the new number as though it had always been there.
Keep one contact address for these questions and make sure somebody watches it during the review window. Applications stall for days because a follow-up went to a personal inbox nobody opened, and the reviewer does not chase it. Where a question arrives that you cannot answer the same day, reply with the date the answer will come rather than leaving the thread silent while the figures are assembled.
Where the page sits on the site
Give it a stable URL that survives a redesign, link it from the footer and from the token section of the documentation, and use that same URL in every application form. A page that lives inside a slide deck or a downloadable file is useless to a reviewer, who wants something to paste into an internal ticket and open again in a month.
Keep it readable without scripts. Some tables render from a data file and show nothing when the request fails, which a reviewer reads as a broken page rather than a loading problem. Plain markup with the figures in the HTML costs nothing and works everywhere the page will be opened, including archived copies and the text-only views that reviewers and indexers sometimes see.
Reconciling the page against the chain
Once a month, open the page next to the explorer and check every figure in order: total supply, each allocation address and its balance, the burn total, the state of each vesting contract. The check takes about as long as the page has rows, and it catches the drift that follows ordinary operations, such as an incentive budget that has been paying out since the last review.
Record the date of the check in the internal document even when nothing changed. That log is what lets you answer a challenge with a specific date rather than an assurance, and it turns the page from a claim into a maintained record. Whoever inherits the page then gets a history instead of a set of numbers with no provenance and no way to tell which of them were ever verified.
Rounding, ranges and figures that move
Decide the precision before publishing and apply it everywhere. Round supply figures the same way in every bucket, state percentages to the same number of decimal places, and never mix a rounded figure in the table with an exact one in the prose. A reviewer who adds the column and lands slightly off total supply has to work out whether the difference is rounding or an omission, and will write and ask.
Where a figure is genuinely a range, such as an incentive budget spent at a variable rate, publish the cap and the amount spent to date rather than a projection. The cap is enforceable and the spend is checkable. A projection is a forecast, and it moves the page into the category of material a reviewer discounts entirely, taking the accurate sections with it.
Translating the page without losing figures
If the site runs translated versions, treat the numbers as shared content and only the prose as translatable. Translated pages that fall behind the original produce the worst kind of mismatch, because every figure is sourced from you and they still disagree. Either generate the tables from one file for all languages, or drop the translation of this page and link the original from each locale.
Check the number formatting as well. A locale that uses a comma as the decimal separator can turn a supply figure into something an order of magnitude away from correct, and automated translation does this without warning. Read the rendered figures in each language rather than the source strings, and do it again after any change to the template that draws them.
When a number on the page is wrong
Correct it on the page first, then notify every surface that copied it: the trackers, any exchange with a live application, and the channels where the figure has been quoted. That order matters, because the first thing anyone does after reading a correction is open the page to check whether it already reflects what the correction says.
Write what changed, when, and why in one short paragraph rather than removing the old figure quietly. Teams underestimate how much credit a fast public correction buys and overestimate the damage of admitting an error. The alternative is somebody else publishing the comparison, and from that point the discussion is about whether the project was misleading rather than about a mistake that has already been fixed.
A clear token page is only part of the story, and our guide to crypto investor relations covers the reporting rhythm that keeps holders informed.
What a good page removes
Projected valuations, price targets and comparisons to the market capitalisation of larger tokens do not belong on it. They add nothing a reviewer values and they make the rest of the page read as promotional rather than factual.
The same applies to charts with no axis labels and percentages that do not sum to one hundred. Both are common, both are noticed immediately, and both cost more credibility than the design gains.
For teams preparing this alongside a listing or launch announcement, the media and disclosure side is covered on our crypto PR page, and the contract verification step in how to verify a token contract.