Skip to content
Financial Context Wiki

Token vesting

Token vesting makes an allocation available according to a schedule. Learn how cliffs and linear release work, what on-chain evidence to verify, and why vested tokens are not necessarily sold tokens.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

Token vesting is a rule that makes a beneficiary’s allocation available according to a schedule rather than all at once. A cliff is a period before the first tranche vests; after it, tokens may vest continuously, in periodic tranches, or at milestones.

Vesting does not itself mean minting or selling. Tokens may already exist while locked, or they may be minted when released. A vested amount may still be unclaimed, non-transferable under another rule, held by the beneficiary, or sold only later.

For analysis, separate five events: allocated, vested, claimed, transferable, and sold. Only the last one is an actual sale, and its price effect depends on market expectations, holder behavior, and executable liquidity.

Increase vs current float
20%
Post-unlock supply
120m
Unlock value at input price
$100m

Outputs are educational approximations. They exclude venue rules, taxes, latency, oracle behavior, and other protocol-specific parameters unless shown.

How it works

  1. Read the legal and published terms. Identify the allocation, beneficiary, start time, cliff, end time, release frequency, milestones, revocation rights, and authority to amend the schedule.
  2. Verify the implementation. Check the token address, vesting contract, beneficiary, timestamps, released amount, claim transactions, proxy or administrator controls, and whether the source code is verified. OpenZeppelin’s VestingWallet is one implementation, not a universal standard.
  3. Reconcile supply labels. Determine whether locked tokens are included in total supply and whether an unlock changes circulating supply without changing total supply. ERC-20 defines token transfer behavior, but it does not define “circulating supply” or require a vesting schedule.
  4. Map the path to market. Vested tokens become potential supply only when they can be claimed and transferred. Deposits to exchanges, bridges, liquidity pools, or new wallets are evidence of movement, not proof of a sale.
  5. Compare scenarios with liquidity. Estimate the fraction that could be sold and compare it with order-book depth or AMM reserves. Report depth separately from trading volume; past volume is not a guaranteed bid.

For a schedule with allocation A, cliff release C, cliff time T_c, and end time T_e, one possible linear rule is:

vested(t) = 0 before T_c; otherwise C + (A - C) × min((t - T_c) / (T_e - T_c), 1)

Real contracts can use different rounding, timestamps, revocation, or milestone logic, so the governing documents and contract code take precedence over this example.

Worked example

A contributor receives an allocation of 12,000,000 tokens. Nothing vests during a 12-month cliff. At month 12, 3,000,000 tokens vest; the remaining 9,000,000 vest monthly over the next 24 months, or 375,000 per month.

At month 18, six post-cliff monthly tranches have vested, so cumulative vesting is 3,000,000 + 6 × 375,000 = 5,250,000 tokens. If 2,000,000 were already claimed, 3,250,000 are vested but unclaimed. This calculation says nothing about how many tokens were transferred or sold.

Suppose 100,000,000 tokens currently circulate and the month-12 tranche becomes transferable. The tranche equals 3% of current circulating supply. If the beneficiary sells 20% of it, the proposed sale is 600,000 tokens, not 3,000,000. Its market impact must be tested against current executable liquidity rather than inferred from the headline unlock.

Risks and checks

  • Incomplete or changeable schedule. Side letters, milestone conditions, administrator keys, governance, or upgrades may alter the published calendar. Record who can change each term.
  • Contract and custody risk. Bugs, compromised keys, wrong beneficiaries, token migrations, or claim failures can delay or redirect releases. Verify addresses and finalized transactions.
  • Supply-classification error. Data providers may treat treasury, locked, bridged, burned, or unclaimed balances differently. Reconcile definitions before calculating percentages.
  • Liquidity and concentration risk. A large tranche held by a few low-cost recipients can overwhelm thin bids, but an unlock alone does not prove they will sell.
  • False precision. Calendars can use block timestamps, seconds, discrete periods, rounding, or manual claims. Use the contract’s actual state near the event, not only a dashboard countdown.

Common misconceptions

“Vested” means “sold”

No. Vesting establishes entitlement under a schedule. Claiming, transferring, depositing, and selling are separate actions that require separate evidence.

A cliff releases the entire allocation

Not necessarily. A cliff only specifies when vesting first occurs. The first tranche and subsequent curve depend on the particular schedule.

An unlock always increases total supply

No. Previously minted locked tokens can become transferable with no change in total supply. Mint-on-release designs can increase total supply; verify the contract and supply accounting.

A large unlock guarantees a price decline

No. Price reflects expectations, demand, hedging, recipient behavior, and liquidity. Treat the sellable fraction and price impact as scenarios, not certainties.

Sources

Navigation

Search the wiki...