What happens to a pair's data when an exchange delists it

A delisting is an exchange decision with a date on it. For a person it is an announcement to read. For a bot or a backtest it is a change of state in an API, and the state the API reports is not always the one its name suggests. This page follows one Binance spot pair from scheduled to delisted to archived, and then the two places downstream — a bot's pair list and a coin aggregator — where the pair's history either survives or quietly drops out.

It does not repeat what a crypto backtest assumes about fills, fees and funding. This is about which pairs the backtest runs on in the first place.

How it works

Three things happen to a pair, usually on different days.

1. It is scheduled. The exchange announces a delist time.
2. Trading stops. The order book empties and no new candles form.
3. The record stays. The pair keeps its symbol in the exchange's metadata, its candles in the API and its files in the archive, under a status that downstream code must interpret.

Each step is visible through a different endpoint, and each library downstream makes its own choice about what the status means.

Before: the delist schedule

Binance publishes upcoming spot delistings at GET /sapi/v1/spot/delist-schedule. Its wallet change log dates the endpoint to 15 January 2024. The reference page, read on 23 October 2026, gives the shape: an object with delistTime, a millisecond timestamp, and symbols, a list of pair names. It is marked MARKET_DATA, costs 100 of IP weight, and requires an X-MBX-APIKEY header — so although it describes public market structure, an anonymous call cannot read it.

That requirement shapes what a framework does with it. In Freqtrade's Binance module, read at the commit of 23 October 2026, check_delisting_time returns nothing at all unless the bot is in a trading run mode; for spot pairs the lookup returns nothing unless the run mode is live, with the comment "Endpoint only works in live mode as it requires API keys". The schedule is cached for 300 seconds. For Binance futures the same function reads each contract's delivery date and treats a date equal to BTC/USDT perpetual's as "never delisted".

Freqtrade's documentation says the same in user terms: its DelistFilter, which removes pairs due to be delisted, works on Bybit futures, Bitget futures and Binance, "where Binance Futures will work for both dry and live modes, while Binance Spot is limited to live mode", and it "does not support backtesting mode". A dry run on Binance spot therefore does not see the schedule.

After: what the API says about a delisted pair

Binance's spot documentation lists five symbol statuses: TRADING, END_OF_DAY, HALT, BREAK and CANCEL_ONLY, the last added in the changelog entry of 1 July 2026. The English file gives no definitions. The Chinese edition does: HALT is "交易终止(该交易对已下线)" — trading terminated, the pair has been taken offline — and BREAK is "交易暂停", trading paused.

What the API returned on 23 October 2026, at about 19:04 UTC and again at 19:46 UTC, for BTCBUSD, a pair whose last candle is dated 15 December 2023:

• exchangeInfo returned the symbol with "status":"BREAK" — not HALT — alongside "isSpotTradingAllowed":true and its full set of filters.
• depth returned an empty book: no bids, no asks.
• klines returned history. The last daily candle opened at 00:00 UTC on 15 December 2023 and closed at 04:59:59.999, five hours into the day, at 42,769.40.
• ticker/price returned 42,769.40, with no timestamp.
• ticker/24hr returned the same last price, zero bid and ask, and a 24-hour window dated 5 to 6 October 2026.

Across the whole spot list, exchangeInfo returned 3,736 symbols at both reads: 1,383 TRADING, 2,353 BREAK, and none HALT.

So on Binance spot the label a delisted pair carries is the one the documentation's Chinese edition describes as a pause, and nothing in exchangeInfo separates a pair resuming tomorrow from one that stopped in 2023. The price endpoints keep answering. A bot that reads ticker/price for a symbol it holds in a list will get a number for a pair that has not traded for almost three years.

Where the history goes

The REST API keeps serving it. Candle history for BTCBUSD was retrievable through klines on 23 October 2026, back to its first daily candle on 19 September 2019 when the request asked for a start time of zero.

The archive keeps it as files. Binance Vision listed 52 monthly files of BTCBUSD daily candles, from September 2019 to December 2023, and the December file downloaded. The archive's licence, which is narrower than its openness suggests, is covered in what exchange API terms let you do.

Aggregators keep the coin, under another status. CoinGecko's coins list "Returns the full list of active coins by default"; coins "no longer listed on CoinGecko" come back only with status=inactive, which needs the Analyst plan or above. CoinMarketCap's Listings Criteria define an Inactive Listing as one set inactive for "absence of market data on at least one CMC-supported exchange or cessation of operations", and reactivate it only with material volume "on at least two CMC-supported exchanges". Its delisting policy, section E, reserves the right to delist a pair, an exchange or an asset "without prior notice". Keeping those IDs is covered in mapping a ticker to one coin.

Why the pair drops out of a backtest universe

The universe a backtest runs on is usually today's market list, filtered — and the filter is where a delisted pair goes.

CCXT turns status into a boolean. Its Binance market parser, read at the commit of 22 October 2026, sets active = (status == 'TRADING'), and sets it false for spot symbols carrying the TRD_GRP_003 permission. BREAK, HALT, END_OF_DAY and CANCEL_ONLY all become active: false.

Freqtrade drops inactive markets from the pair list, in backtests too. Its pair-list base class removes a pair that is not in the loaded markets, and logs "Ignoring from whitelist. Market is not active." for one whose market is inactive. StaticPairList runs that check whatever the run mode, and in backtesting and hyperopt it caches the result for the run. The documentation's answer is an option on the static list: "By default, only currently enabled pairs are allowed. To skip pair validation against active markets, set "allow_inactive": true", which it describes as "useful for backtesting expired pairs".

Dynamic lists cannot look back. Freqtrade's VolumePairList and DelistFilter are among the handlers its documentation marks as not supporting backtesting. A universe chosen by today's volume is chosen from today's survivors.

The result is mechanical, not a choice anyone made: with Freqtrade's defaults, a backtest of 2023 run in October 2026 on Binance spot keeps only the pairs that CCXT marked active — trading — in October 2026.

What it costs

The schedule and the history are free; the cost is an API key and a plan.

• Delist schedule: no charge beyond having a Binance account and an API key; 100 of IP weight per call.
• Exchange history: klines and Binance Vision files are free to fetch, under the licence terms of each.
• Aggregator history of inactive coins: on CoinGecko, the inactive list needs the Analyst plan or above, priced on the CoinGecko API card.

What you can do about it

Do not read BREAK as temporary on Binance spot. Treat any status other than TRADING as "not tradable now", and decide separately, from the schedule or from the date of the last candle, whether it will come back.

Check the age of every price you act on. ticker/price carries no timestamp and keeps answering for a delisted pair. Read the close time of the last kline, or the trade time of the last trade, and refuse a price older than your own threshold.

Read the delist schedule in the process that trades. It needs a key, so put the call where the key already is. In Freqtrade on Binance spot, that means the live bot; a dry run will not see it.

Freeze the universe when you build it. For a backtest, save the pair list of the period you are testing — from the archive's file listing or your own snapshot of exchangeInfo — and pass it as a static list with allow_inactive set, rather than asking the exchange for today's list.

Keep inactive IDs. Store CoinGecko and CoinMarketCap IDs for coins that stopped trading, flagged rather than deleted, so that a series still joins to its coin after the coin has gone.

Download the archive before you need it. History was still served on 23 October 2026 for a pair delisted in December 2023. Neither the API documentation nor the archive promises that it always will be.