A token unlock is a scheduled change in how many tokens may become transferable. It is easy to look back at a few large unlocks, see a falling chart, and conclude that unlocks push prices down. That reading usually mixes three problems: unclear supply definitions, schedules that were revised after the fact, and a sample made of the tokens that are still easy to find today. This guide treats an unlock as an event to be registered before its outcome is examined, then measured against a benchmark with windows chosen in advance.
Separate the supply numbers first
Several supply figures are often shown side by side, and they answer different questions. Circulating supply is a provider’s estimate of tokens currently available to trade; its methodology decides which wallets are excluded. Total supply usually counts tokens that exist now, including locked allocations. Maximum supply is a cap, if the protocol defines one. Market capitalization is commonly quoted price multiplied by circulating supply, while fully diluted valuation (FDV) multiplies price by a larger supply figure. Providers do not all use the same inputs, so record which supply figure and which source you used. The guide to market cap, price and supply explains why neither number is cash invested or a guaranteed sale value.
For unlock research, the useful ratio is often the scheduled release divided by circulating supply as it stood before the event, not as reported months later. A release that equals 8% of circulating supply is a different event from one that equals 0.5%, even if both make headlines. Size alone still says nothing about who will sell. Reading an unlock schedule without predicting a crash covers cliffs, linear releases and why transferable does not mean sold.
Register the event and the date it became knowable
The central rule is simple: for each event, record what a researcher could have known before the measurement window opened. That means saving:
- the token, network and contract or mint address;
- the schedule document, its publisher, version and first-published date;
- the unlock date and time in UTC, and the scheduled amount by recipient category;
- the circulating-supply figure, its provider and retrieval date;
- any later revision, kept as a separate record rather than overwriting the original.
Schedules change. A project may delay a cliff, restructure an allocation or publish a corrected table after an unlock has passed. If your dataset quietly uses the latest version, an event can appear with a release size that nobody saw at the time. That is look-ahead bias in a supply dataset; the look-ahead bias checklist covers the same mistake in price backtests. Who receives the tokens also matters for interpretation, but labels need care: token-holder concentration analysis explains why an address list does not reveal intent.
Define windows and a benchmark before measuring
An event study compares what happened around an event with a reference for what might have happened otherwise. MacKinlay’s event-study review describes the goal as measuring an economic event’s effect on firm value using prices around the event date, and notes that the method has potential complications. Crypto adds round-the-clock trading, venue-specific prices and common market shocks, so state your model plainly.
Before collecting returns, fix:
- the event window, for example from the daily close five days before the unlock to the close five days after;
- the price source, venue and close time in UTC;
- a benchmark measured over identical timestamps, such as a broad crypto index or a peer group chosen by a written rule;
- inclusion and exclusion rules, including overlapping events on the same token;
- what happens when data ends early.
The benchmark matters because a whole market can fall during the same week. Prices move for many reasons at once, as the guide to why crypto prices move explains, so a benchmark-relative difference is a measurement, not proof of cause.
A fictional worked example
The table below is entirely invented. Each row is a registered unlock, measured from day −5 to day +5 against a benchmark over the same closes.
| Event | Schedule version known before window | Release vs. prior circulating supply | Token return | Benchmark return | Difference |
|---|---|---|---|---|---|
| A | v1, published 90 days earlier | 4.0% | −6.0% | −2.0% | −4.0 pp |
| B | v1, published 60 days earlier | 1.5% | +3.0% | +4.0% | −1.0 pp |
| C | v2, published 30 days earlier | 8.0% | +2.0% | −1.0% | +3.0 pp |
| D | v1; a v3 published after the event is ignored | 2.5% | −3.0% | −3.5% | +0.5 pp |
| E | v1; token delisted on day +3 | 6.0% | data ends | −1.5% | flagged |
Across the four complete events, the average difference is (−4.0 − 1.0 + 3.0 + 0.5) ÷ 4 = −0.375 percentage points. Remove event C and the average becomes about −1.5 points; remove A and it turns positive. Four observations cannot support a general conclusion, and the example shows how one case can flip the reading. Event D uses the schedule that existed before the window, not the later revision. Event E stays in the register with its missing data stated. These figures are arithmetic from made-up inputs, not results from any token or venue.
Survivorship: count the tokens that disappeared
If you build a sample from a token list downloaded today, tokens that were delisted, migrated or abandoned may be missing. Those are often the cases with the weakest outcomes, so leaving them out can make unlocks look milder than they were. Build the universe from what was listed and scheduled as of each registration date, and record delistings, contract migrations and data gaps as outcomes rather than reasons to drop a row. A missing price after delisting is unknown, not zero and not a recovery.
Test the design before trusting the average
Once the register is frozen, challenge it. Try a second benchmark chosen in advance, a shorter and a longer window, placebo dates with no scheduled release, and a split between earlier and later events. Report the number of events screened, included and excluded, with reasons. If the pattern exists only in one window or one recipient category you picked after viewing charts, treat it as a hypothesis for new data. The out-of-sample testing guide explains how to hold back later events for a single honest check.
Supply is one input among many. Token use, holder rights, demand and liquidity also shape value, as what gives a crypto asset value sets out, and none of them yields a reliable formula.
SuperQuant is a research workspace: its included examples use synthetic hourly data, it does not place live orders, and its results describe a simulation rather than verified live returns. Register each supply event from your own dated sources rather than from a calendar compiled after the fact.
Keep learning
The evidence-first learning path walks through testable questions, dated sources and honest records in plain language. For the wider method around catalysts and timestamps, read the event-driven research timeline. This is educational research context, not investment advice.