Correcting Survivorship in a Launch Dataset Before You Backtest

Launch strategies backtest well, and they backtest well for a reason that has nothing to do with the strategy. The universe you can query today is the set of tokens that are still queryable today, and the ones that are missing did not leave at random. They left because they stopped having a pool, a price, or anything for a data pipeline to attach to. Every one of those is a loss you did not record.

This is the oldest bias in quantitative research and it has a sharper edge here than in equities. A delisted stock still has a CUSIP, a final price, and a corporate action record. A token that goes to zero liquidity has an address, an empty pool, and no obligation on anyone to keep a row about it anywhere.

The three ways the dead leave your table

The first is deletion at source. A live feed is a picture of what currently exists. The launches ledger in the screenshot shows 100 of 3,771 rows across nine chains, and 3,771 is a count of what the module holds now. Whether a token that died in March is still in that 3,771 is a question about retention policy, not about your query, and it is the first thing to establish empirically. Pull rows dated at least ninety days back and look for entries with zero or near-zero liquidity. If none come back, the feed is a survivor set and any retrospective universe you build from it is already contaminated.

The second is join failure. Even where a dead token's row persists, the fields you need for a return calculation may not. A price series sourced from a drained pool returns nulls, and a pipeline that drops nulls has just deleted exactly the observations carrying the worst outcomes. Almost every data-cleaning step in existence silently removes the losses by default.

The third is your own key. Token symbol is a free text field with no uniqueness guarantee, so a symbol-keyed table merges unrelated contracts, and any relabelling of a name or symbol on the vendor side breaks the link between an old observation and a current one. The only stable key is the chain identifier plus the contract address, and that has to be the primary key from the first row you write.

An append-only universe file with a status that only transitions

The correction is structural rather than statistical. You do not adjust for survivorship after the fact, you build a table that cannot lose rows in the first place.

Primary key is chain plus contract address. A row is written once, on first observation, and is never deleted or overwritten. It carries a first-seen timestamp, the origination date from the ledger's Date field, and a status. Observations of the numeric fields go into a separate time-series table keyed to the same address, one row per address per snapshot date.

Status is the part people get wrong, because they use a single alive-or-dead flag and lose the information that distinguishes very different events. A taxonomy that survives contact with a research meeting needs at least five states, and the transitions have to be one-directional and timestamped.

That last row is where a lot of research tables get corrupted. The suite carries Launches, Listings and Delistings as separate tabs, and a delisting there is an exchange announcement. A venue removing a pair is not the same event as a token dying on chain, and folding the two into one dead flag both overstates mortality and destroys your ability to study either.

Every field must be as-of, and the ledger serves current

Survivorship is the loud bias. Look-ahead is the quiet one, and on this dataset the two arrive together, because the same table that is missing the dead is also serving you today's values for the living.

Liquidity, holders, market cap and volume as displayed are current. If you build a signal that says "enter when liquidity exceeds two hundred thousand dollars" and you evaluate that condition against a liquidity figure pulled today, you are selecting tokens that reached two hundred thousand dollars at some point, which is a substantially different and much more successful population than tokens that had it on day one. The only fix is snapshots. Capture on a schedule, store the value with the observation date, and let the backtest read the snapshot table rather than the live one.

The same applies to any derived verdict field. On the capture in front of me the Score and Safety columns are empty on every visible row, so there is nothing to backfill, but the general rule holds regardless of coverage. Any field that could have been computed or revised after the fact must be timestamped and read as of the decision date, or excluded. A risk verdict that arrived a week after launch cannot be an input to a day-zero entry rule, and there is no way to enforce that except by storing when you saw it.

What the corrected universe does to the headline numbers

The deflation is mechanical and it is worth putting numbers on so the desk understands the magnitude before the corrected run comes back.

Suppose you observe 1,000 launches in a period, and by your measurement date 400 are still present in a queryable form. Run the strategy on those 400 and it reports a 45 percent hit rate. If the 600 that vanished are treated as losses, which is the appropriate default for tokens that reached zero liquidity, the corrected hit rate on the full universe is 18 percent. The identity is simple. Observed hit rate multiplied by the survivor share, plus whatever hit rate you assign to the dropouts, which for this failure mode is zero.

Those figures are an illustration of the arithmetic, not a measurement of any real cohort. Substitute your own survivor share and the point holds at any values, because the mechanism does not depend on the numbers.

The effect on mean return is larger than the effect on hit rate, and this is the part that gets missed. A dropout is not a small loss, it is close to a complete one, and complete losses have unbounded influence on an average. A strategy showing a healthy mean return on survivors can have a negative mean on the corrected universe while its hit rate still looks respectable, because the surviving winners are capped by liquidity on the way out and the dead losers are not capped at all. Report both, and report the median alongside the mean, because on this distribution the mean is describing a handful of names.

The leaks that persist after the file is fixed

Capacity is the one that invalidates the study rather than merely biasing it. A corrected hit rate computed at a position size the pools could never have absorbed is not a result. Every entry has to be marked with the impact of the size you would actually have traded, using the liquidity as of the entry snapshot, and every exit has to be marked the same way. Rows in the capture carry pool depth in the tens to hundreds of thousands of dollars against market caps in the millions to tens of millions. Institutional size does not fit through that, and a backtest that ignores it is measuring a strategy nobody could run.

Sampling is the second. If your capture pulls the top 100 by market cap or volume rather than paging the full population, you have re-introduced survivorship through the front door after removing it from the back. Document the capture method in the same file as the results.

The third is the one that will come up in the review, so have the answer ready. Even a perfectly retained universe is conditioned on the vendor having seen the token at all. Launches that never reached whatever ingestion threshold the feed applies are absent from the 3,771 and absent from your file, and their absence is unmeasurable from inside the dataset. That is a stated limitation rather than a solvable problem, and stating it is the difference between a research note that survives scrutiny and one that gets quietly shelved.