How to Prepare Documents for an Exchange Listing Application

Direct answer

An exchange listing application needs four documents: a whitepaper describing the deployed contract, a tokenomics document with allocations and a dated vesting schedule, an audit report naming its auditor and covering the deployed version, and team information identifying who is accountable. CoinDock accepts these as PDF, DOCX, PNG, or JPG, up to 20 MB per file. The decisive quality is not thoroughness — it is that all four agree with each other and with what the contract actually reports.

The principle

A reviewer opens your documents alongside a block explorer. Every number that appears in more than one place is a chance for the two to disagree, and every disagreement is a round trip that costs days.

So the work is less about writing more and more about reconciling what you have.

Step 1 — Build a facts table first

Before touching any document, write down the canonical values, reading each from the chain where possible:

Now make every document match this table. This single step removes most of the delay projects experience.

Step 2 — The whitepaper

It must describe the contract you deployed, not the one you intended to deploy. Whitepapers are typically written before launch and frequently drift.

Re-read yours specifically looking for:

• Supply figures that no longer match the contract.
• Described features that were not implemented, or were implemented differently.
• A token model that changed during development.
• Chains listed that you did not ultimately deploy on.

If it has drifted, you have two honest options: update the document, or attach a short addendum stating what changed and why. Either is fine. Submitting a stale whitepaper without acknowledgement is what causes trouble.

Step 3 — The tokenomics document

This is where most reviewer questions originate, so make it specific.

Allocations — every bucket, as both percentage and absolute token count, summing to total supply. Team, treasury, investors, community, liquidity, ecosystem.

Vesting — as a table, not prose:

"Tokens vest over 24 months with a 6-month cliff" is a description of a schedule. A reviewer needs the schedule.

Lock enforcement — if locks are enforced on-chain, give the lock contract addresses so they can be verified. A verifiable lock is worth considerably more than a stated intention.

Flag near-term unlocks. Anything landing in the next 90 days should be called out explicitly. An unlock a reviewer discovers looks like something you hoped they would not.

Step 4 — The audit report

• Attach the report itself — not a badge, a certificate image, or a link to a marketing page.
• Name the auditor.
• State clearly which version was audited and whether it is the deployed one.
• For each unresolved finding, say what was done: fixed, mitigated, accepted with reasoning. Unresolved medium findings are survivable; unexplained ones are not.

If you have no audit, say so plainly rather than implying one exists. Some listings proceed without one depending on the token and the venue. An overstated audit claim discovered later is worse than an honest absence.

Step 5 — Team information

The purpose is accountability, not identity theatre. Someone must be reachable after listing, because questions arrive: a migration, an exploit, a chain halt, a support case needing a project-side answer within hours.

Include roles, relevant background, and a monitored contact channel. If your team is pseudonymous, explain the structure and who holds decision-making authority — pseudonymity is normal in this industry, but unreachability is not.

Step 6 — Format and package

• PDF, DOCX, PNG, or JPG. PDF is preferable for anything with layout.
• Under 20 MB per file. Compress image-heavy documents; a 40 MB whitepaper full of uncompressed screenshots will not upload.
• Name files usefully — projectname-tokenomics-2026-06.pdf, not final_v3_REAL.pdf.
• Check they open. A corrupted or password-protected upload stalls review just as effectively as a missing one.

Step 7 — Read them together, once

Open all four side by side and check:

• Total supply identical everywhere, and matching the contract.
• Circulating supply consistent, with its measurement date stated.
• Allocation percentages summing to 100%.
• Vesting totals reconciling to the allocation table.
• Contract address identical in every document.
• Chain named consistently.
• Audit version matching the deployed version, or the difference noted.
• Contact details identical and monitored.

The test to apply

Could a stranger verify every claim using only the chain and these four files, without asking you anything?

If yes, your application moves quickly. Every "no" is a question, and questions are what make listings slow.

Related

• Token Listing Checklist — the full pre-application checklist.
• How to Pass Smart Contract Review — the audit and disclosure side.
• Project Review Process — how these documents are used.