What a Crypto Exchange Requires Before Listing a Coin

Direct answer

An exchange reviewing a listing needs to establish six things: the token's on-chain identity (contract address, chain, verified source), its supply and vesting schedule, which privileged functions the contract carries and who controls them, who is accountable for the project, the legal position in relevant jurisdictions, and how liquidity will exist after the pair opens. Requirements vary by exchange, but these six categories are near-universal.

Why these six, and not others

A listing requirement that does not map to a failure mode is bureaucracy. Each of these does:

Identity: the contract address is the token

Names and ticker symbols are just strings stored inside a contract. Nothing stops anyone deploying a second contract that calls itself by the same name and ticker as a well-known project. This is one of the most common ways buyers end up holding something worthless while believing they hold something real.

The contract address is different. It is derived from the deployment transaction and is unique on its chain. It is the only reliable identifier a token has.

Two consequences follow:

• The address must come from a source the project controls — its own domain, its own verified account — never from a search result or an inbound message.
• The same project may deploy on several chains with different addresses. An address valid on one chain is meaningless on another, and sending tokens to the wrong network's address can destroy them irrecoverably.

Verified source code on a block explorer matters for the same reason. Without it, a reviewer is trusting a description of the contract instead of reading the contract.

Supply: circulating is not total

Two numbers, and the gap between them is usually the interesting part.

• Circulating supply — tokens actually available to trade today.
• Total supply — every token that exists or will exist, including team allocations, treasury, and tokens still locked in vesting contracts.

A project with 10% of supply circulating has a fully diluted valuation ten times its market capitalisation, and the locked 90% will eventually reach the market. A reviewer wants the vesting schedule specifically so that a large unlock cannot arrive unannounced into a book that cannot absorb it.

Providing this is not a disadvantage. A clearly disclosed unlock schedule is a much better position than one discovered later.

Privileged functions: disclose, do not hide

Many legitimate contracts carry functions that can mint new tokens, pause transfers, blacklist addresses, or take a fee on transfer. These are not automatically disqualifying — pause functions in particular have saved projects during live exploits.

What matters is disclosure and control:

• Which privileged functions exist?
• Who holds the keys that can call them — a single address, a multisig, a timelock?
• Under what circumstances would they be used?

A fee-on-transfer token deserves particular attention because it interacts badly with exchange accounting: the amount received differs from the amount sent, and an integration that does not expect this produces balance discrepancies. Declaring it up front avoids a failed integration late in the process.

Undisclosed privileged functions found during review are treated far more seriously than disclosed ones, because at that point the question stops being about the contract and becomes a question about the disclosure.

Accountability

Someone must be reachable after listing. Not because anonymity is inherently suspect — parts of this industry are pseudonymous by design — but because questions arrive: a contract migration, an exploit, a chain halt, a support case needing a project-side answer within hours.

A project that cannot be contacted is a project whose users have nowhere to go.

Liquidity: a listed pair is not a traded pair

This is the requirement projects most often underestimate. Listing creates a venue. It does not create a market.

A pair with no resting orders shows a wide spread, produces heavy slippage on any real order, and lets a single small trade reprice the entire supply on paper. That outcome is worse for a project than not listing, because it is publicly visible.

So a reviewer asks a concrete question: who is going to quote both sides of this book, with what inventory, from day one? An answer naming a market maker, or a specific treasury allocation and a plan to deploy it, is a real answer. "The community will provide liquidity" is not.

What CoinDock's application actually collects

CoinDock's listing application is a four-step form. Knowing its shape in advance makes it faster to complete:

1. Project identity — project name, coin name, ticker, chain, and contract address.
2. Public references — website URL, block explorer URL, whitepaper URL.
3. Supporting documents — whitepaper, audit report, team information, and tokenomics. Accepted as PDF, DOCX, PNG, or JPG, up to 20 MB per file.
4. Review and submit.

An application then moves through submitted → review → approved or rejected. You need a CoinDock account to start one, because the application is tied to an applicant and produces a record you can return to.

Requirements and fees can change. The listing application page is authoritative — treat this page as guidance on what to prepare, not as the current terms.

Common mistakes

• Submitting the address of a liquidity pool or a proxy rather than the token contract. These are different addresses with different meanings.
• Supplying a whitepaper that describes an intended contract rather than the deployed one. Reviewers compare the two.
• Writing "audited" without naming the auditor or providing the report. An unnamed audit is not evidence.
• Treating the liquidity question as a formality. It is the requirement most likely to determine whether the pair actually works.
• Paying anyone who approaches you offering a listing. Applications start from the exchange's own published process, never from an inbound offer.

Related

• Token Listing Checklist — the same material as a working checklist.
• Project Review Process — what happens after you submit.
• USDT Pair Listings — why pairs are quoted in USDT and what that implies.