Crypto and CryptoFuture delisting support

[AlexCatarino]

Summary

Historical hourly trade/quote data for several Binance USDⓈ-M perpetual futures
contracts is present in the QuantConnect cloud data store, but the contracts
have no row in Data/symbol-properties/symbol-properties-database.csv under
type=cryptofuture, so AddCryptoFuture(...) cannot subscribe to them (the
security service throws Failed to resolve base currency for '<TICKER>', it might be missing from the Symbol database or market '<MARKET>' could be wrong, Common/Securities/SecurityService.cs:152).

Evidence

The following tickers were once tradeable Binance USDⓈ-M futures contracts
(all later delisted from the futures venue by Binance) and have complete
historical trade+quote hour files in the cloud store
(cryptofuture/binance/hour/<ticker>_trade.zip /
cryptofuture/binance/hour/<ticker>_quote.zip both exist for each), yet none
of them has a type=cryptofuture row in the current
symbol-properties-database.csv:

• AKROUSDT
• BTTUSDT
• BZRXUSDT
• DODOUSDT
• KEEPUSDT
• LUNAUSDT
• NUUSDT
• YFIIUSDT

All eight tickers do still have a type=crypto (spot) row in the same file,
which is not equivalent - AddCryptoFuture specifically requires a
cryptofuture row (see Common/Securities/Crypto/Crypto.cs:139, which reads
SymbolProperties.QuoteCurrency to decompose the currency pair; without a
matching row the default account-currency quote is used instead, the ticker
does not end with it, and CurrencyPairUtil.TryDecomposeCurrencyPair fails).

Suspected root cause

symbol-properties-database.csv's cryptofuture rows appear to be
regenerated from Binance's current exchangeInfo listing. Once Binance
delists a USDⓈ-M futures contract, its row silently drops out of the next
regeneration - even though the previously-collected historical files for that
ticker remain valid and stay in the data store indefinitely. The result is
that historical data becomes permanently unreachable through the normal
subscription API for any contract Binance later delists, despite the data
itself being intact.

Proposed fix

The cryptofuture generation step should preserve a symbol's row once
delisted (or fall back to the last-known row) rather than dropping it,
similar to how equity delistings do not remove historical map-file/security
entries. Where the historical row differs from the current listing, the
row should be flagged (e.g. by an IsDelisted/last-active-date column) or
delisted rows appended after a snapshot, so AddCryptoFuture can still
resolve the currency pair for periods when the contract was live.

Open questions

• Is symbol-properties-database.csv's cryptofuture section generated by
  an automated job or hand-maintained? If automated, is the generator in this
  repo or an internal pipeline?
• Are there other delisted Binance USDⓈ-M contracts with the same gap beyond
  the eight sampled here?

Reported via Intercom conversation 215475946234200.

[Martin-Molinero]

See related issue #9801 . It's both crypto and crypto future delisting support.

[zahT3]

Checked both questions against the repos.

Q1: the generator is in Lean. ToolBox/ExchangeInfoUpdater.cs rewrites the file; the Binance feed is in QuantConnect/Lean.Brokerages.Binance (BinanceExchangeInfoDownloader.cs). Not an internal pipeline, and nothing runs it on a schedule - updates arrive as PRs (#9054 Oct 2025, #9734 Aug 2026).

The proposed fix is already implemented, so it would not close this gap. WriteData merges every previously known entry for the market back into the downloaded set ("let's keep any existing which is no longer available, to take into account for delistings/removals"), so the file is add-only. On #9734: binance,cryptofuture symbols 718 -> 806, 0 removals, 88 additions.

So the rows were never created. The downloader reads the current exchangeInfo, so a contract is only captured if an update ran while Binance still returned it. That matches the file today:

• A2ZUSDT, 42USDT, EPTUSDT, OMUSDT are still returned as SETTLING and do have rows (the four from Crypto future funding keeps being applied from a stale cached MarginInterestRate after the contract's data ends #9801).
• The eight tickers here are gone from exchangeInfo (897 symbols, none match), and git log -S finds no commit that ever added a cryptofuture row for any of them.

That points the fix upstream (seed from historically listed contracts), or into resolution (AddCryptoFuture accepting a missing cryptofuture row, e.g. falling back to the same ticker's crypto row).

Q2: filtering the CSV alone (has a crypto row, ends in USDT, no cryptofuture row, absent from exchangeInfo) gives 232 candidates; intersect with the data store for the exact list.