By CrowdSent Blog Team
To understand token vesting vs token unlock, distinguish allocation rules from availability and actual transfers. Vesting describes the rules under which an allocation becomes available over time or after specified conditions. An unlock is a point or process at which a restriction is lifted. A release or claim is the actual transfer of available tokens to the recipient. These events can occur at different times.
Terminology varies between projects and contracts, so a schedule’s labels need checking. A calendar entry saying that tokens “unlock” does not, on its own, prove that the tokens were transferred, became part of a data provider’s circulating-supply figure or were sold.
This guide compares the stages using a hypothetical allocation. It explains cliffs, cumulative amounts, cancellation rights and the difference between a scheduled supply event and observed market liquidity.
Token vesting vs token unlock: rules, availability and release
A vesting schedule defines the progression of an allocation. It might make equal amounts available each second, release installments on specified dates or hold the full allocation until one date. An unlock describes availability under those rules.
A release is a separate accounting event when the contract actually sends available assets to the beneficiary. In a claim-based implementation, the passage of time changes what can be released without automatically producing a transfer at every moment.
OpenZeppelin’s Contracts 5.x finance documentation illustrates this distinction through separate values for vested amounts, releasable amounts and amounts already released. Its default VestingWallet uses a linear schedule, while extensions and custom implementations can change the rules.
These are examples of contract behavior, not a universal legal definition of entitlement. A project’s documents, deployed implementation and applicable agreement may use the same word differently. When reading market data, preserve the source’s meaning rather than silently assuming that every “vested” amount is already transferable.
The fields that determine a schedule
The starting point is the allocation size and recipient category. Then identify the schedule’s start, end, cliff if any, and the way availability progresses between dates.
A cliff usually creates an initial interval with no available withdrawal under the schedule. What happens at the cliff is crucial: some arrangements make an accumulated portion available immediately; others begin a new progression after the cliff. “Six-month cliff” alone does not determine the amount released on that date.
Another distinction is continuous versus periodic availability. A smooth line can make a fraction available each second. A staircase can make a fixed amount available each month. Those shapes can have the same end date and total allocation but different intermediate balances.
Sablier’s stream-shape documentation provides primary examples of linear, cliff, tranched and timelock structures. The practical lesson is to read the actual curve and parameters instead of interpreting a generic “vesting” label as one standard shape.
A worked 120,000-token allocation
Consider a hypothetical grant of 120,000 tokens over 24 equal accounting months. Assume a six-month cliff with catch-up: nothing is available before month six; at month six, 30,000 tokens become available. Thereafter, another 5,000 becomes available at each monthly boundary through month 24.
The schedule is deliberately defined in accounting months for easy arithmetic. A real implementation may use exact timestamps in seconds, and calendar months do not all have the same length. An actual contract must be evaluated using its own time rules.
At month six, the cumulative available allocation is 30,000. At month nine it is 45,000: the cliff amount plus three installments of 5,000. At month 24 the cumulative amount reaches the full 120,000.
Read the month-nine position without double-counting
Assume the contract was funded with all 120,000 tokens at the start. The beneficiary claimed 30,000 at month six and made no further claims before the month-nine snapshot.
At month nine, the schedule has made 45,000 available cumulatively. Of that amount, 30,000 has already been released and 15,000 remains claimable. The remaining 75,000 has not yet become available under the schedule.
The contract still holds 90,000 tokens: 15,000 claimable plus 75,000 unavailable. Reading the entire 90,000 contract balance as “still unvested” would overstate the restricted portion. Reading 45,000 as a fresh month-nine unlock would mistake a cumulative total for a new installment.
The correct month-nine installment is 5,000. The outstanding claimable amount is 15,000 because earlier available installments were not claimed. These quantities answer different questions even though they all appear in the same schedule.
Why an unlock need not create new tokens
In the prefunded example, all 120,000 tokens already exist before the cliff. They move from restricted custody to claimable status and, when released, to the beneficiary. Those steps do not themselves create additional units.
A different implementation could mint tokens as part of a release process. That possibility must be established from its rules and observed events; it should not be inferred from the word “unlock.” A transfer of existing units and creation of new units are different supply events.
The impact on a circulating-supply dataset also depends on the provider’s classification. A beneficiary’s identity, restrictions and the source’s inclusion rules may affect when units are treated as circulating. A calendar does not automatically establish that classification.
For the related valuation context, CrowdSent’s explanation of crypto market capitalization and price shows why the supply measure behind a number matters. Here the focus is the transition from schedule to availability to actual release.
Cancellation and transferability change the interpretation
A schedule can be conditional on whether its creator retains cancellation rights. In some implementations, cancellation returns the still-unvested portion while leaving the already-vested portion attributable to the recipient. In others, the relevant rules differ or cancellation is unavailable.
Sablier’s Lockup cancellation documentation distinguishes cancelable and uncancelable streams and identifies what happens to unstreamed funds. That is a specific implementation example, so its behavior should not be assumed for every vesting contract.
There is a second question: can the claim to future tokens change hands before the tokens themselves are released? A transferable receipt or ownership right can allow the beneficiary to change while the original schedule continues.
Sablier’s transferability documentation explains that its stream NFT can be transferable or nontransferable. This separates transfer of the claim from release of the underlying assets.
Consequently, “tokens are locked” does not establish that every economic interest in them is immovable. Conversely, seeing a receipt transfer does not prove that the underlying token allocation has fully unlocked. Identify which object moved.
How an unlock connects to market liquidity
An unlock can enlarge the set of tokens available for a recipient to use, subject to remaining restrictions. What happens next is another question. Tokens may remain at the beneficiary’s address, move to another contract or be exchanged. The schedule itself does not reveal that choice.
Consider a hypothetical 50,000-token unlock. The number describes available units under a defined schedule. It does not state that 50,000 tokens entered an exchange, that a matching buyer exists or that a liquidity pool can absorb an exchange of that size at an unchanged price.
Market depth requires its own evidence. CrowdSent’s liquidity versus volume guide explains the difference between available capacity and recorded activity. Neither is supplied by an unlock calendar alone.
The same caution applies to decentralized-finance incentives. A program might distribute tokens to liquidity providers according to a schedule. The scheduled incentive amount is separate from swap fees, actual active liquidity and the value of a provider’s pool claim.
Likewise, a vesting contract’s token balance is not evidence that those tokens are currently usable as AMM inventory. Restrictions, ownership and the location of assets matter. A research note should connect those facts only when the relevant movements are observed.
Reconcile the announcement, schedule and on-chain record
A project announcement can explain intended allocations and dates. A deployed schedule shows the implementation parameters. A confirmed release event or balance change supplies evidence that an actual transfer occurred. Each source answers a different part of the story.
For a scheduled event, record the token contract, network, recipient category, amount, denominator and exact time basis. “Two percent unlock” needs a denominator: two percent of the grant, current circulating supply or another defined quantity can describe very different amounts.
Then distinguish forecast from observation. A date derived from a published schedule remains a scheduled date until the relevant condition and event are established. If an implementation requires a claim transaction, the transfer may occur later than the availability time.
Changes should be dated too. A revised allocation announcement, governance decision or replaced implementation can make an older calendar entry stale. CrowdSent’s guide to verifying market news provides a useful framework for tracing a claim back to its original source.
Frequently asked questions about token vesting and unlocks
1. Is token vesting the same as a token unlock?
Vesting describes the progression or conditions of an allocation; an unlock describes availability when a restriction lifts. A schedule can contain many unlocks. The project’s terminology may differ, so verify how it defines each term before comparing calendar entries.
2. What is the difference between unlocked and claimed?
Unlocked tokens are available under the relevant rules. Claimed tokens have actually been released through the required process. In a claim-based contract, available amounts can accumulate while no transfer occurs. The beneficiary’s claimable balance and released balance should therefore be reported separately.
3. Does a cliff always release the full allocation?
No. A cliff can make a portion available, allow accumulated vesting to become claimable or mark the start of a later progression. A full-allocation timelock is another possible design. The cliff date alone does not specify its amount.
4. Are monthly and continuous vesting equivalent?
They can share the same total and endpoint while differing between dates. Continuous vesting makes amounts available progressively; monthly tranches change availability at defined boundaries. A screenshot taken between those boundaries can therefore show different claimable amounts.
5. Does an unlock automatically increase total token supply?
No. Prefunded allocations contain existing tokens, and releasing them changes their location or availability. If a release mechanism also mints units, that is a separate implementation feature requiring evidence. The unlock label does not tell you which mechanism applies.
6. Why can a contract balance exceed the unvested amount?
It may hold both unavailable tokens and tokens already available but not yet claimed. In the worked example, the month-nine balance is 90,000, while only 75,000 remains unavailable. The other 15,000 belongs to the claimable portion.
7. Can a vesting schedule be canceled?
Some implementations allow cancellation and specify how remaining assets are allocated; others do not. Check the actual rights and contract state. A project’s general description of “long-term vesting” does not establish whether cancellation is possible or who controls it.
8. Can a recipient transfer a vesting claim before release?
Sometimes. A receipt token or transferable ownership right can change the beneficiary while the underlying tokens remain subject to the schedule. Other designs restrict transfers. Transferring the claim and releasing the underlying tokens are different events and need different evidence.
9. Does an upcoming unlock prove that selling will occur?
No. It identifies a potential change in availability, subject to the schedule and other restrictions. Actual selling requires separate transaction or market evidence. Recipient behavior, liquidity and other conditions cannot be established from the unlock amount alone.
10. What should a trustworthy unlock entry include?
It should identify the asset, network, source, recipient category, incremental amount, exact time basis and schedule assumptions. Percentages need a denominator. It should also distinguish scheduled availability, cumulative availability and completed releases so readers do not confuse them.
Conclusion: follow availability through to the actual event
The useful distinction between token vesting and token unlock is a sequence of evidence: the schedule defines the rule, an unlock changes availability, and a release records a transfer. Keeping cumulative, claimable and released amounts separate prevents common supply and liquidity mistakes.
Use this guide to interpret token-distribution claims with clear timestamps, quantities and source boundaries.
Source documentation checked 11 October 2026. Educational explanation from the CrowdSent Blog Team. Numerical examples are hypothetical unless explicitly identified otherwise. This article does not provide investment recommendations.