Token Listing Checklist — What to Have Ready Before You Apply

Direct answer

Before applying to list a token, have ready: the verified contract address and chain, name, symbol and decimals confirmed on-chain, total and circulating supply with a dated vesting schedule, a written disclosure of every privileged contract function and who controls it, an audit report covering the deployed version, whitepaper and tokenomics documents that agree with the chain, identifiable and reachable team contacts, and a concrete liquidity plan naming who will quote the market.

Section 1 — On-chain identity

Everything else depends on these. If they fail, nothing downstream is assessed.

• Contract address recorded exactly, with no truncation or transcription error.
• Chain stated unambiguously, including which network if the project deploys on several.
• Source code verified on a public block explorer.
• Name, symbol, and decimals read directly from the contract and confirmed to match your documents.
• Total supply read from the contract, not from a document.
• Confirmed the address is the token contract, not a liquidity pool, a proxy admin, or a treasury wallet.

Read your own contract on an explorer before submitting. A surprising proportion of applications are stalled by a mismatch the applicant could have found in two minutes.

Section 2 — Contract behaviour disclosure

Write these down even where the answer is "none." An explicit "no mint function" is evidence; silence is a question.

• Mint — can new tokens be created? By whom?
• Burn — can tokens be destroyed, and by whom?
• Pause / freeze — can transfers be halted?
• Blacklist — can specific addresses be blocked?
• Transfer fee / reflection — does the amount received differ from the amount sent?
• Upgradeable proxy — can the implementation be replaced?
• Key control — for each of the above: single key, multisig, or timelock? Which addresses?

Fee-on-transfer behaviour deserves a specific callout to the exchange. It breaks accounting assumptions that most integrations make, and finding out late usually means restarting the integration.

Section 3 — Supply and vesting

• Circulating supply with the date it was measured.
• Total supply, reconciled against the contract.
• Allocation breakdown — team, treasury, investors, community, liquidity.
• Vesting schedule as a table of dates and amounts, not a prose description.
• Lock contracts identified by address where locks are enforced on-chain.
• Any unlock in the next 90 days flagged explicitly.

Section 4 — Documents

• Whitepaper — describing the deployed contract, not an earlier intention.
• Tokenomics document — consistent with both the whitepaper and the chain.
• Audit report — naming the auditor, covering the deployed version. If it covers an earlier version, say so rather than letting a reviewer discover it.
• Team information — real, contactable people or a clearly explained pseudonymous structure.

CoinDock accepts these as PDF, DOCX, PNG, or JPG, up to 20 MB per file.

The most common documentary failure is not a missing document. It is three documents that disagree with each other. Read them side by side before submitting.

Section 5 — Legal position

• Jurisdictions where the token is offered, and any restrictions on holders.
• Legal opinion, where the token's characteristics warrant one.
• Any regulatory correspondence or registration relevant to the token.
• Confirmation that nobody involved appears on applicable sanctions lists.

Section 6 — Liquidity plan

The item projects most often skip, and the one that most determines whether the listing works.

• Who quotes the market — named market maker, or an internal team with the capability.
• Inventory committed on both sides: quote-asset funds for bids, tokens for asks.
• Target spread you intend to maintain.
• Depth you intend to keep resting within a few percent of the midpoint.
• Duration of the commitment.

"The community will provide liquidity" is not a plan. See what is token liquidity.

Section 7 — Operational readiness

Easy to overlook, and each has stalled real listings:

• A monitored contact address — review generates questions, and unanswered questions are the main cause of delay.
• Someone available during the listing window itself.
• Communications ready but unpublished — no listing date announced before approval.
• Community informed about the correct contract address, to blunt the impersonator tokens that reliably appear around a listing.
• A decision on who speaks for the project if something goes wrong on day one.

Section 8 — Before you press submit

• A CoinDock account, since the application is tied to an applicant.
• Every document opened and re-read once more for internal contradictions.
• Contract address copied from the explorer, not retyped.
• Payment channel verified on the exchange's own domain — never from an inbound message.

The single most useful test

Before submitting, ask: could a stranger verify every claim in this application using only the chain and the documents attached, without asking me anything?

If yes, the application will move quickly. If no, each gap is a round trip, and round trips are what make listings slow.

Related

• Coin Listing Requirements — why each requirement exists.
• Project Review Process — what happens after submission.
• How to List Your Coin on CoinDock — the step-by-step walkthrough.