New token listing: why exchanges reject 90% of applicants

No exchange-wide dataset, named venue disclosure, or independently auditable applicant denominator establishes it.

The underlying observation is still directionally correct: most listing submissions do not move quickly from application to trading. The reason is less mysterious than the figure suggests. A listing is not a marketing placement. It is an operational decision with legal, technical, liquidity, and reputational exposure. Each missing document, unverified supply field, inactive market, or unsupported network increases review latency. Several such gaps usually stop the process altogether.

For a token team, the practical question is not whether an exchange rejects “90%.” It is whether the project can clear the sequence of filters that precedes an approval decision.

A listing application fails less often on one dramatic defect than on accumulated variance between what the project claims, what its onchain data shows, and what the venue can verify.

The anatomy of exchange due diligence

A CEX does not evaluate a token through a single checklist. It evaluates a package of evidence. The exact exchange listing requirements vary by venue, but the structure is broadly consistent: identity, legal status, technical integrity, token economics, demand, and operational feasibility.

Coinbase’s published process provides a useful reference point because it specifies the input fields. Its listing application requests a whitepaper, team background, tokenomics, source-code links, block explorers, and third-party audit material where available. These are not decorative attachments. They are the initial dataset from which reviewers test internal consistency.

A project can present a polished whitepaper and still introduce immediate review friction if the following fields do not align:

• The stated circulating supply differs from the supply visible through the explorer or token contract.
• Vesting allocations appear in tokenomics but lack wallet-level disclosure, contract references, or release schedules.
• The legal entity named in a whitepaper is absent from website terms, exchange correspondence, or jurisdictional documents.
• The contract address in the application differs from the address promoted on official channels.
• An audit refers to a predecessor contract, while the deployable token uses a later implementation.
• The source repository is public but lacks a release tag or a verifiable connection to the deployed code.

These are not minor editorial defects. They create an attribution problem. A reviewer must determine whether the submitted representation can be attributed to the asset that will actually trade. If the chain of evidence is incomplete, approving the asset transfers avoidable risk to the venue.

Coinbase also states that incomplete information about governance, tokenomics, or technical documentation can delay evaluation. Failure to report material changes during review can do the same. This is significant for projects that treat the application as a static form. It is not static. A token migration, supply adjustment, new unlock, bridge deployment, or governance change can alter the original risk profile.

The practical baseline is simple: the application must match the live asset at the moment of review, not the asset described in an early deck or token launch announcement.

Documentation is an integration dependency

Teams sometimes separate “listing documentation” from product work. Exchanges do not. Documentation determines whether operational teams can integrate, monitor, and support the asset.

A listing candidate therefore needs a coherent documentation layer:

1. Token identity. Contract address, chain, decimals, token standard, block explorer, official website, and official social accounts must resolve to the same asset without ambiguity.

2. Technical architecture. The exchange needs to understand custody assumptions, minting authority, upgradeability, bridges, dependencies, and whether token transfers contain restrictions or unusual logic.

3. Supply mechanics. Maximum supply, circulating supply, burned tokens, locked balances, vesting contracts, staking allocations, treasury holdings, and market-making inventory need a common accounting frame.

4. Governance and control. Reviewers need to see who can pause, mint, upgrade, blacklist, alter fees, or change material token parameters.

5. Incident history. Exploits, migrations, contract replacements, previous token versions, and bridge events require disclosure rather than omission.

The relevant measure is not document volume. It is reconciliation time. If a reviewer can move from a supply claim to an explorer address, then to a vesting contract, then to a published allocation schedule without finding variance, the asset is operationally legible. If every answer requires a separate follow-up, latency expands.

Compliance is not a post-listing task

The technical review is only one layer. The legal and compliance layer often determines whether a token can move into integration at all.

Coinbase describes its process as including business factors, legal issues, compliance, and technical security. This wording matters because a project may be technically sound and still create an unacceptable legal exposure for a specific venue or jurisdiction.

For projects seeking admission to trading in the European Union, the Markets in Crypto-Assets Regulation adds a more explicit disclosure baseline. Under MiCA, a person seeking admission to trading for a crypto-asset other than an asset-referenced token or e-money token generally must be a legal person and must prepare, notify, and publish a crypto-asset white paper. The disclosure scope includes the project, token rights and obligations, underlying technology, risks, and environmental impacts.

MiCA does not convert all exchange decisions into a uniform formula. Exchanges still apply internal policies, risk thresholds, and jurisdiction-specific controls. But it reduces the margin for vague materials. A token with unclear issuer information, undefined holder rights, or incomplete risk language creates a direct compliance burden.

Promotional language can also introduce avoidable variance. Price-appreciation claims, return expectations, and statements implying guaranteed market outcomes are not harmless community messaging when they sit beside a listing request. Coinbase specifically identifies such statements as potentially increasing regulatory risk.

The operational implication is direct: marketing, legal, and tokenomics teams cannot run separate narratives. If social channels frame the token as an investment outcome while the legal materials define a utility or governance function, the discrepancy becomes part of the diligence record.

The fastest route through compliance review is not aggressive positioning. It is a stable record: one issuer, one supply model, one description of token rights, and no conflict between public claims and submitted evidence.

How exchanges quantify demand rather than impressions

A frequent error in new token listing strategy is to substitute audience size for market demand. A large follower count is not a liquidity signal. It is not necessarily an active-holder signal either.

Coinbase states that listing priority and timing can be influenced by demand metrics including trading volume, market capitalization, and liquidity. It also points to traction indicators such as holders, active wallets, total value locked, and onchain activity. Community sentiment and team track record are qualitative inputs, but they do not replace measurable market structure.

This creates a distinction between visibility and tradability.

An exchange evaluates these signals as a set. A project with 100,000 holders but negligible active wallets may have distribution without usage. A token with high reported volume but shallow executable depth may have activity without reliable price formation. A protocol with rising TVL but no evidence of retention may have incentives rather than durable demand.

The question is not whether the token can produce one attractive metric. The question is whether several independent datasets point in the same direction.

This is where tokenomics becomes measurable. Unlock schedules affect prospective sell-side inventory. Treasury concentration affects potential market impact. Market-maker allocations affect quote durability. Incentive emissions affect whether volume represents organic turnover or subsidized circulation. None of these fields automatically disqualifies an asset. Hidden or inconsistent fields do.

For a listing team, the useful internal model is:

Listing readiness = verifiable documentation + legal clarity + technical integration feasibility + observable traction + sustainable liquidity

Each term is necessary. Strength in one term does not cancel a zero in another.

CoinGecko is a separate filter, not an exchange listing

CoinGecko is often placed in the same operational bucket as centralized exchanges. That is inaccurate. It is a data and tracking platform, and its token listing evaluation serves a different purpose: determining whether the asset can be represented reliably in its market-data environment.

Its published criteria still expose recurring weaknesses in project submissions.

CoinGecko requires a functional project-owned website with adequate project information, a working block explorer, trading on at least one active exchange integrated with CoinGecko, and clear communication of circulating supply. That supply disclosure should account for locked, vested, team, foundation, and developer allocations.

The standard is not “the token exists.” The standard is whether users can identify the token, inspect it, locate a market, and interpret its supply.

CoinGecko also requires a public verification post from an official social-media account linked to the project website. The process includes supplying the post URL and replying to the original post with the request ID after receiving it. This is an identity-control mechanism. It binds the request to an account that the website itself recognizes as official.

A submission that lacks this linkage has an obvious attribution problem. A project representative may be legitimate, but the platform needs a public and reproducible proof path rather than private assertion.

Regular evaluation typically takes three to five working days. CoinGecko indicates that if a token remains unlisted after two weeks, it likely did not pass evaluation. Its Fast Pass service is described as expedited review processing within 24 hours. It is not a paid listing guarantee.

Teams should also note the platform’s caution around tokens traded only on self-service centralized or decentralized exchanges. Such assets may be rejected because of security concerns. The presence of a pool or a self-created market is therefore not equivalent to an eligible market-data listing.

For teams mapping venue coverage, a current comparison of crypto exchanges and their market access models can be useful context. It does not replace the listing criteria of a specific venue, but it helps separate marketplace visibility from exchange-level integration requirements.

Liquidity is a mechanism, not a balance figure

Liquidity is often discussed as a treasury line item: a project allocates a certain number of tokens and stablecoins, deposits them somewhere, and treats the requirement as solved. That approach ignores the mechanism through which traders encounter liquidity.

On a centralized exchange, the relevant variables include order-book depth, quoted spread, replenishment speed, inventory management, adverse-selection exposure, and the market maker’s ability to maintain two-sided quotes during volatility. A nominal liquidity commitment without stable quoting behavior has limited value.

On a DEX, the mechanism depends on the protocol design.

In Uniswap v2, the standard pool swap fee is 0.30%. Liquidity is distributed across the full price curve. This is operationally simple but capital is not concentrated around the active trading range.

Uniswap v3 and v4 use concentrated liquidity. A provider selects a price range. The position earns swap fees only while the market price remains within that range. Once the price exits the selected interval, that liquidity becomes inactive and stops earning fees until the price re-enters.

This changes the meaning of “liquidity provision.” The pool may show a substantial total value locked figure while the usable depth near the current price is weak. It also means that a passive deployment can become operationally inactive without any failure at the protocol level.

Uniswap v3 has standard fee tiers of 0.05%, 0.30%, and 1%. In v4, pool creators can set fees from 0% to 100% in increments of 0.0001%. Fee selection is not a cosmetic configuration. A fee that is too low may not compensate liquidity providers for volatility and rebalancing exposure. A fee that is too high can suppress routing and volume. The right baseline depends on expected volatility, correlated assets, trade size, and competing pools.

The price grid also matters. In Uniswap, one tick represents a 0.01% price movement. Range selection therefore has direct consequences for capital efficiency and rebalance frequency. Narrow ranges can generate fees efficiently when price remains stable. They also increase the probability that a position moves out of range during ordinary volatility.

A credible liquidity plan should state more than the starting deposit. It should specify:

• The intended venue split between CEX order books and DEX pools.
• The inventory source for market making and the rules governing replenishment.
• The target spread and depth bands, stated internally as operational parameters rather than promotional claims.
• The monitoring cadence for out-of-range concentrated positions.
• The authority that can rebalance liquidity, change ranges, or deploy additional inventory.
• The relationship between unlock events, emissions, and expected sell-side pressure.
• The method for distinguishing organic flow from incentive-driven volume.

No official source establishes a universal minimum for liquidity, market capitalization, holder count, or market-maker budget. Such thresholds vary by venue, chain, asset type, and prevailing market conditions. A team claiming that one fixed dollar amount “qualifies” a token for exchange listing is substituting a sales script for an evaluation model.

Nor does hiring a market maker guarantee approval, faster integration, stable launch pricing, or sustained liquidity. A market maker can improve market structure only within the inventory, mandate, technology, and risk controls available to it.

The measurable baseline for a new token listing

The new token listing process is not a binary test of whether a project appears legitimate. It is a sequence of reconciliation tasks. The exchange, data platform, and liquidity venue each ask a related question: can this asset be identified, integrated, monitored, and traded without introducing unbounded operational variance?

Coinbase states that token due diligence takes about one week on average. Trading can be enabled within two weeks after approval, while end-to-end review to listing is generally under 30 days. Those figures are not deadlines. Asset complexity, network support, responsiveness, and integration work can materially change the timeline.

That is the correct way to interpret listing latency. It is not merely waiting time. It is unresolved work.

The usable formula is therefore:

Approval probability rises when documentation variance falls, compliance attribution is complete, traction is independently observable, and liquidity remains executable under normal market movement.

There is no verified 90% rejection statistic to optimize against. There is a more practical baseline: every unsupported claim, missing contract reference, unexplained supply change, and inactive market adds review friction. Remove those variables before the application enters the queue.