Crypto token unlocks make a scheduled allocation eligible for release or transfer, but they do not prove that the tokens entered circulation or were sold. Measure potential dilution against a clearly dated supply figure, then verify the vesting terms, release transactions and data provider's circulation rules. An unlock calendar records eligibility; it does not forecast price.
A headline such as “6% of supply unlocks” leaves several questions unanswered. Six percent of which supply? Do recipients need to claim? Are the tokens already counted as circulating? A useful unlock note answers those questions before discussing possible market effects.
Separate five states before reading an unlock calendar
Use the following as operational labels in your research. The project's actual agreements and deployed contracts determine what each allocation permits; a calendar's terminology may differ.
| Field | What to record | What it does not establish |
|---|---|---|
| Vested | Amount whose vesting conditions have been satisfied under the applicable schedule | That every transfer restriction has expired |
| Unlocked or releasable | Amount now eligible for the specified release or transfer | That a release transaction occurred |
| Released | Amount actually delivered from the vesting arrangement to the beneficiary | That ownership passed to public holders |
| Circulating | Amount included under a named supply provider's methodology | That the entire amount is offered for sale |
| Transferred | Observed movement between specified addresses | That a sale occurred or the beneficial owner changed |
OpenZeppelin's documented VestingWallet implementation makes a useful distinction concrete: it exposes separate readings for vested, releasable and already released amounts, plus a release operation that transfers vested assets to the beneficiary. Its default vesting curve is linear, and a cliff extension is available. This is one implementation, not evidence about an unidentified project's contract. OpenZeppelin finance contract documentation
Do not add these fields together. A token can be vested, releasable and still held in the vesting contract at the same instant. After release it can also be sitting in a beneficiary wallet excluded from a provider's circulating figure. These labels describe different properties of overlapping balances.
For a simple funded arrangement without other restrictions, unreleased vested tokens equal cumulative vested tokens minus cumulative released tokens. Record both readings at the same observation time. Custom schedules, additional locks or administrative controls require their own reconciliation.
Circulating supply is a classification, not a calendar total
CoinMarketCap explicitly distinguishes circulating supply from unlocked supply. Its methodology generally excludes specified insider and strategic allocations from circulation even when unlocked. A release into a team wallet therefore does not, by itself, establish an equal increase in its reported circulating supply. CoinMarketCap supply methodology
CoinGecko documents a calculation for smart-contract tokens that subtracts identified locked balances from total supply, using project disclosures and explorer data where available. That process depends on the addresses and classifications used. Attribute the figure to CoinGecko rather than presenting it as an undisputed property shared by every provider. CoinGecko circulating-supply methodology
When two providers disagree, compare the supply definitions, excluded wallets, observation times and verification status. Replacing one figure with another midway through a calculation can create an apparent supply change without any token moving.
The related market capitalization versus FDV guide explains how the choice of supply changes a valuation denominator. Here the narrower task is to establish which supply state actually changed at an unlock.
A hypothetical cliff: 60 million eligible, 20 million released
Every quantity and relative time in this example is invented. It describes no live token, upcoming event or KLINEO result.
Assume a token has 1 billion already minted tokens, with 200 million counted as circulating immediately before time T. A separate 60 million allocation sits in three fully funded vesting wallets, each holding 20 million. Nothing in this allocation vests before T. All three reach the same cliff at T, when their specified schedules make the entire allocation vested and releasable; no new tokens are minted.
Assume the chosen supply methodology excludes unreleased allocations and beneficiary insider balances. At T plus one day, it counts 5 million tokens distributed without restrictions to public recipients. This classification is an explicit assumption for this example, not a claim that any provider would automatically adopt it.
| Observation | Vested but unreleased from this allocation | Cumulative release to beneficiaries | Total counted circulation |
|---|---|---|---|
| Just before T | 0 | 0 | 200 million |
| T: all three cliffs pass; nobody claims | 60 million | 0 | 200 million |
| T + 2 hours: one wallet releases its 20 million | 40 million | 20 million | 200 million |
| T + 1 day: that beneficiary distributes 5 million to public recipients | 40 million | 20 million | 205 million |
At the last observation, the allocation reconciles as 40 million still in vesting wallets, 15 million retained by the beneficiary and 5 million held by public recipients. Those balances sum to 60 million. The other 740 million noncirculating tokens and the original 200 million circulating tokens remain unchanged by assumption.
Calling this a “60 million sale at T” would be unsupported. Calling it a “20 million increase in circulation” would also contradict the stated methodology. The observed increase is 5 million, and even the public distribution need not be a sale: the example supplies no payment or execution evidence.
Compute dilution with an explicit denominator
The scheduled allocation is 60 million / 1 billion = 6% of minted total supply. Against the pre-event circulating supply, it is 60 million / 200 million = 30%. Both calculations are correct, but they answer different questions.
The 30% figure describes the scheduled amount relative to the old circulating base. It does not measure the observed circulation increase at T, which is zero in the example. By T plus one day, the measured increase is 5 million / 200 million = 2.5% under the assumed classification.
For a separate, explicitly hypothetical case in which all 60 million eventually enter circulation, the new base would be 260 million. An unchanged holding of 2,000 tokens would represent 0.001% of the original 200 million circulating base and about 0.000769% of the new base. That is a 23.08% relative reduction in its share of the circulating denominator, calculated as 1 − 200 / 260.
Its share of the 1 billion minted tokens remains 0.0002%, because this example mints nothing. Distinguish expansion of counted circulation from creation of additional tokens. Do not translate either percentage mechanically into an expected price change: a supply ratio alone contains no evidence about demand, recipient behavior or executable market depth.
If a schedule instead involves future minting, record that separately. Also keep staking emissions distinct from releases of already minted allocations. The staking APR versus APY guide addresses reward calculations; an annual reward rate cannot substitute for this allocation's release ledger.
Keep the schedule clock separate from the observation clock
An unlock record needs more than a date. Capture the schedule's effective time and timezone, the time of the contract observation, the release transaction's block and timestamp, and the provider figure's observation or update time. Those times can differ without contradicting one another.
A continuous schedule also needs an interval. An amount described as “unlocked this month” may summarize many small increments rather than one cliff at midnight. Verify whether a calendar cell gives an incremental amount during the period or a cumulative amount vested to date before summing several cells.
For on-chain movement, retain the network, token contract, transaction identifier, sender, recipient and units. ERC-20's Transfer event records addresses and a value; it does not include sale consideration or an exchange fill. The inference is limited: the event alone cannot establish a sale. Address labels and additional transaction evidence need separate checking. ERC-20 transfer event specification
An exchange deposit can be a preparation step, custody movement or collateral transfer. It does not reveal an eventual order's execution. Likewise, several wallet hops can move the same tokens repeatedly; summing gross transfers would overstate the distinct supply released.
Resolve the common failure cases before publishing
A project announcement may describe a planned schedule while a later governance decision or contract change alters it. Preserve the original note, inspect the relevant later evidence and state whether your conclusion describes a plan or an observed release. The AI crypto news verification guide provides a source ledger for checking announcement status.
Another failure is treating a missing provider update as evidence that no release occurred. Check the contract state and the provider's classifications separately. Conversely, a changed circulating figure can reflect an updated wallet exclusion rather than a new unlock. Ask which balance or rule changed.
Finally, avoid using today's corrected schedule as though it were the information available in an earlier event study. Save the version and retrieval time used for each analysis. The backtest data revision guide explains why revised history and previously available evidence answer different questions.
Save a worksheet that another reader can reconcile
Use one row per allocation, not just one row per token. Team, investor and treasury allocations can have different recipients, schedules and restrictions.
| Worksheet field | Required entry |
|---|---|
| Identity | Network, token address, allocation and beneficiary or custodian |
| Schedule evidence | Official URL, retrieved version, effective timestamp, timezone and cliff or continuous rule |
| Release conditions | Claim requirement, additional restrictions and evidence for any schedule change |
| Before and after | Vested, releasable, released and relevant wallet balances at identified observations |
| Circulation basis | Provider, excluded addresses, timestamp and reason for any reclassification |
| Denominators | Pre-event circulating supply, minted total supply and the source of each |
| Movement evidence | Transaction references, recipient classification and evidence needed before calling a transfer a sale |
| Reconciliation | Allocation balance check, observed circulation change and unresolved differences |
If AI helps prepare the note, require it to populate those fields with evidence and mark unavailable values as unknown. An unsupported field should stay unknown even when several calendars repeat the same number.
For the worked example, the defensible note is precise: 60 million became releasable at T; 20 million were released two hours later; 5 million entered the assumed circulating classification by the next day. Save those separate statements, their observation times and their denominators before drawing any further conclusion.