Token Vesting Contracts Explained: Cliff, Linear, and On-Chain Schedules

Token vesting is the mechanism that prevents early stakeholders — founders, team members, investors, advisors — from immediately selling their token allocations after a project launches. Without vesting, there is nothing stopping an early participant from receiving 10% of the token supply at launch and immediately dumping it on the market. Vesting enforces long-term alignment by releasing tokens gradually over a defined schedule. This guide explains every vesting mechanism used in production token projects, how on-chain vesting contracts work, and how to deploy one for your token.

What Is Token Vesting?

Token vesting is the practice of releasing tokens to a beneficiary according to a predetermined schedule rather than transferring the full allocation at once. Instead of handing a founder or investor their entire token grant on day one, a vesting contract holds those tokens in escrow and releases them incrementally over a defined period.

Two parties are always involved. The protocol or project sets the vesting schedule — the total amount, the timeline, and any cliff conditions. The beneficiary is the recipient: a founder wallet, an investor address, an advisor, or a DAO contributor. The tokens sit locked inside a smart contract. The beneficiary can only claim the portion that has vested so far; any unclaimed but vested tokens continue accumulating in the contract until claimed.

Key terminology you need to understand:

• Vesting period: The total duration over which 100% of the allocation releases. Industry standard is 2 to 4 years for team tokens.
• Cliff: A mandatory initial period where zero tokens are released. The first release happens at the end of the cliff.
• TGE unlock: A percentage released immediately at the Token Generation Event, before any vesting begins. Common for public sale participants.
• Release cadence: How often tokens release after the cliff — per block, per day, per month, or in discrete tranches.

Vesting is standard practice for team tokens, advisor allocations, seed and private round investors, and ecosystem grant recipients. It is rarely applied to public sale tokens, which tend to have short lockups or immediate liquidity. For an in-depth look at how vesting fits into your overall token supply design, see our ERC-20 tokenomics guide.

Why Vesting Matters: Preventing Rug Pulls and Dumps

The case for vesting comes down to one core principle: if the people who receive the most tokens can sell them all on day one, they have no economic reason to keep building. This misalignment of incentives has destroyed more crypto projects than almost any other single factor.

During the 2021 and 2022 DeFi boom, dozens of projects launched with minimal or no vesting. The pattern was predictable: TGE, immediate dump by insiders, retail investors left holding worthless tokens, project abandoned. Vesting does not eliminate this risk entirely, but it shifts the calculus dramatically — if founders must wait 3 to 4 years to access their full allocation, they have a strong incentive to keep the project alive and growing.

The practical benefits of on-chain vesting include:

• Rug pull prevention: Founders cannot liquidate their entire allocation at launch. A well-designed vesting schedule means any exit takes years.
• Investor confidence: Institutional investors and VCs treat vesting as a minimum condition of investment. No vesting schedule often means no institutional capital.
• Market stability: Gradual token release prevents sudden large unlocks that crush price. A schedule that releases 1% of supply per month is far less disruptive than one that releases 25% on a single date.
• Team retention: Unvested tokens create a financial incentive for team members to stay. Someone who leaves forfeits their unvested allocation.

Cliff Vesting: How It Works

A cliff is a defined period at the start of a vesting schedule during which absolutely no tokens are released to the beneficiary. When the cliff period ends, a lump sum releases immediately — representing all tokens that would have accrued during the cliff period under the linear schedule.

The canonical example is the standard Silicon Valley equity vesting model, which crypto projects have largely adopted: a 1-year cliff on a 4-year total vesting schedule. Here is how that plays out for a beneficiary receiving 1,000,000 tokens:

• Months 1 through 12: zero tokens released. Beneficiary cannot claim anything.
• Month 12 (cliff end): 250,000 tokens (25%) release immediately in a single transaction.
• Months 13 through 48: the remaining 750,000 tokens release linearly at approximately 20,833 tokens per month.
• Month 48: final tranche released, 100% of allocation fully vested.

The cliff serves a specific purpose: it enforces a minimum commitment period before any reward is granted. If a team member or early contributor leaves within the first year, they receive nothing. This filters out opportunistic participants who join a project only to collect early token allocations.

In Solidity terms, a cliff is typically implemented as a timestamp check. The contract stores a cliff variable equal to the deployment timestamp plus the cliff duration in seconds. Any call to release() before that timestamp simply returns zero available tokens. Only after block.timestamp > cliff does the contract begin calculating releasable amounts.

Linear Vesting: Gradual Release

Linear vesting releases tokens at a constant rate over time. After the cliff period ends (or from day one if there is no cliff), the beneficiary accumulates tokens continuously. The rate is simply: total allocation divided by total vesting duration.

Consider a 1,000,000 token allocation over 36 months after a 12-month cliff. Once the cliff expires, the beneficiary earns approximately 27,778 tokens per month, or about 924 tokens per day, or roughly 38 tokens per hour. At any point after the cliff, the beneficiary can call release() and receive all tokens that have vested since the last claim.

There are two main variants of linear vesting in production contracts:

• Per-second (or per-block) linear: The most granular approach. The contract calculates vested tokens as (elapsed seconds / total duration seconds) * total allocation. The beneficiary can claim at any time and receives exactly the accrued amount. This is the approach used by OpenZeppelin VestingWallet and is considered best practice for on-chain vesting.
• Monthly tranches: Tokens release in discrete monthly batches. Simpler to understand for non-technical beneficiaries, but requires either the team to push transactions monthly or the beneficiary to claim once per period. Less gas-efficient if claimed frequently.

Per-second linear vesting is strongly preferred for on-chain implementations because it is fully deterministic, requires no off-chain triggers, and is straightforward to audit. The beneficiary always knows exactly how many tokens they can claim at any given block.

For guidance on how linear vesting integrates with your broader token design, including allocation percentages and supply mechanics, see our ERC-20 tokenomics guide.

Milestone-Based Vesting

Milestone-based vesting releases tokens when specific project achievements are met rather than on a fixed time schedule. Examples include: the token price reaching a defined threshold, total value locked (TVL) surpassing a milestone, a product version launching, a governance proposal passing, or an audit completing.

The key challenge with milestone vesting is that milestones must be verified before tokens release. On-chain verification is difficult for most real-world outcomes. You generally have three options:

• Oracle-based: A price oracle like Chainlink can verify on-chain data (token price, TVL). Trustless but limited to measurable on-chain metrics.
• Multisig committee: A trusted group of signers (e.g., 3-of-5 multisig) confirms that a milestone was reached and approves the token release. More flexible but introduces centralization risk.
• DAO governance vote: Token holders vote to confirm a milestone was achieved. Transparent but slow and subject to governance attacks.

Milestone vesting is rarely used as the primary mechanism for team tokens. It is more common for ecosystem grant programs, where a developer or team receives tranches of tokens tied to delivering specific features or achieving usage targets. In most cases, it is combined with time-based vesting: a base linear schedule plus bonus unlocks for hitting milestones.

Standard Vesting Schedules by Stakeholder

Different stakeholder groups typically have different vesting terms based on their role, risk profile, and expected commitment horizon. The following table reflects market norms as of 2026 for Ethereum-based projects seeking institutional investment:

A critical rule of thumb: team vesting should always be longer than investor vesting. If investors are locked for 18 months and founders are locked for the same or less, the incentive structure is broken. Founders should be last to fully unlock, not first.

Note also that treasury and ecosystem fund tokens, while often presented as community-owned, should still be vested or release-scheduled. Tokens sitting in a multi-sig controlled by the founding team with no release schedule are functionally equivalent to founder tokens without vesting.

On-Chain vs Off-Chain Vesting

When a project announces a vesting schedule, it can implement that schedule in one of two ways: on-chain via a smart contract, or off-chain via a manual process run by the team. The difference in trust, transparency, and verifiability is enormous.

On-chain vesting means a smart contract holds the tokens and enforces the schedule autonomously. Key properties:

• Transparent: Anyone can read the contract on Etherscan and verify exactly how many tokens are locked, the beneficiary address, the cliff date, and the release rate. See our guide on how to verify a smart contract on Etherscan to understand how to make this information publicly readable.
• Trustless: The contract executes exactly as coded. No team member can delay, accelerate, or cancel the release schedule (unless the contract includes explicit admin functions).
• Verifiable before committing: Investors can confirm the vesting terms are actually encoded in the contract before signing any agreements or sending funds.
• Gas cost: Deployment costs gas (typically $10 to $30 on mainnet at moderate gas prices), plus the beneficiary pays a small gas fee each time they call release().

Off-chain vesting means the team manually sends tokens to beneficiaries on a schedule they maintain in a spreadsheet or internal system. Properties:

• Requires full trust: The beneficiary has no recourse if the team delays or refuses to send tokens. There is no enforceable mechanism.
• Not verifiable: Investors cannot independently confirm the schedule will be honored.
• Lower initial cost: No deployment gas required. Acceptable for very small, early-stage projects with a small number of trusted participants.
• Acceptable ceiling: Any project that has raised more than a seed round from external investors should use on-chain vesting. Off-chain is not acceptable at scale.

For any serious token project — particularly those seeking exchange listings or institutional investment — on-chain vesting is the only defensible choice. It removes the need for trust and replaces it with verifiable code.

Using OpenZeppelin VestingWallet

OpenZeppelin's VestingWallet is the most widely used and audited vesting contract implementation in the Ethereum ecosystem. It is part of the OpenZeppelin Contracts library, which has been audited by multiple security firms and is used in billions of dollars of deployed contracts. For a broader look at OpenZeppelin's utility for ERC-20 projects, see our OpenZeppelin ERC-20 guide.

The contract releases ETH and any ERC-20 tokens linearly over a configurable duration. Its three constructor parameters define everything:

• beneficiaryAddress: The wallet that will receive the vested tokens. Cannot be changed after deployment.
• startTimestamp: The Unix timestamp at which linear vesting begins. To implement a cliff, set this to block.timestamp + cliffDurationSeconds. From the beneficiary's perspective, no tokens vest before this timestamp.
• durationSeconds: How long the linear release lasts after the start timestamp. A 3-year vest is 3 * 365 * 86400 = 94,608,000 seconds.

Key functions you should know:

• release(address token): Called by anyone (though typically the beneficiary) to transfer all currently vested and unclaimed tokens to the beneficiary address.
• vestedAmount(address token, uint64 timestamp): A view function that returns how much of the allocation vests by a given timestamp. Useful for building dashboards or verifying schedule calculations off-chain.
• released(address token): Returns how much has already been claimed by the beneficiary.

Critically, OpenZeppelin VestingWallet has no admin functions. Once deployed, no one can pause, modify, or cancel the vesting schedule. This is by design — it provides maximum trust guarantees to the beneficiary. If you need revocability (the ability to cancel unvested tokens if a team member leaves), you must implement a custom contract or use a third-party vesting platform that supports revocation via multi-sig.

How to Deploy a Vesting Contract

The following walkthrough deploys OpenZeppelin VestingWallet using Remix, the browser-based Solidity IDE. No local toolchain is required. This is suitable for teams deploying one to a few vesting contracts on mainnet or testnet.

Step 1: Set up Remix and create the contract file

Open remix.ethereum.org in your browser. In the File Explorer panel, create a new file named VestingWallet.sol.

Step 2: Import OpenZeppelin

Paste the following into your new file:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/finance/VestingWallet.sol";

Remix will automatically resolve the OpenZeppelin import from npm. No additional setup is needed.

Step 3: Compile

Click the Solidity Compiler icon in the left sidebar. Select compiler version 0.8.20 or later and click Compile VestingWallet.sol. You should see a green checkmark with no errors.

Step 4: Configure deployment parameters

Switch to the Deploy and Run Transactions panel. Under Environment, select Injected Provider - MetaMask to deploy to a real network (or the JavaScript VM for local testing). You will need to provide three constructor arguments:

• beneficiaryAddress: The recipient wallet address (e.g., 0xAbc123...)
• startTimestamp: The Unix timestamp when vesting begins. For a 1-year cliff from now, calculate Math.floor(Date.now()/1000) + 31536000 in the browser console.
• durationSeconds: For 3 years of linear vesting: 94608000

Step 5: Deploy and fund the contract

Click Deploy. MetaMask will prompt you to confirm the transaction and pay the gas fee. After the transaction confirms, copy the deployed contract address from Remix. Then send your ERC-20 tokens to that contract address — this is how you fund the vesting contract. If you created your token using ERC Token Creator, you can use the token's mint() function (if mintable) or a standard transfer to send the allocation directly to the vesting contract address.

Step 6: Verify on Etherscan

Verifying the contract source code on Etherscan is essential for transparency. Follow our step-by-step Etherscan verification guide to publish the source code. Once verified, anyone can read the vesting parameters — beneficiary, start date, duration — directly from Etherscan without needing to trust your documentation.

Step 7: Claiming vested tokens

After the start timestamp passes, the beneficiary can call release(tokenAddress) from any Ethereum wallet interface (MetaMask via Remix, Etherscan's Write Contract tab, or a custom frontend). The contract calculates the vested amount minus any previously released amount and transfers it to the beneficiary wallet. This can be called as frequently or infrequently as desired — unclaimed vested tokens accumulate in the contract and release all at once when release() is eventually called.

For an example: a 1-year cliff plus 3-year linear vest for 1,000,000 tokens would use:

• startTimestamp = current Unix time + 31,536,000 (seconds in one year)
• durationSeconds = 94,608,000 (seconds in three years)

After one year elapses, the beneficiary can call release() and will receive 0 tokens (since vesting only begins at the start timestamp). On day 1 after the start timestamp, approximately 9,132 tokens will have vested (1,000,000 / 94,608,000 seconds * 86,400 seconds per day). After the full 3-year duration, all 1,000,000 tokens will be fully vested.

The Investor Perspective: What to Check

If you are evaluating a token project as an investor — whether seed, private, or public round — the vesting structure is one of the most important due diligence factors. A poorly designed vesting schedule is a leading indicator of future price catastrophe or project abandonment. Here is what to verify before committing capital:

1. Is vesting actually on-chain?

Ask for the vesting contract address. If the team cannot provide one, or says vesting is "coming soon" or "handled internally," that is an immediate red flag. On-chain vesting should exist before or at the time of TGE for any project seeking external investment. Verify the contract on Etherscan yourself.

2. What is the TGE unlock percentage?

Any TGE unlock above 20% for team or early investors is aggressive. A 0% TGE unlock for all insiders signals strong alignment. For your own allocation as an investor, a 5 to 10% TGE unlock is standard for seed rounds. If you are being offered 50% TGE unlock as a "seed investor," that is not a seed structure — re-examine the deal terms.

3. How long is the cliff?

A cliff of less than 6 months for team or core investors is a red flag. The standard is 12 months for founders. Any project where founders can access tokens within the first 6 months of launch has a structural misalignment problem.

4. Are team tokens locked longer than investor tokens?

This is a fundamental alignment check. If the team fully vests in 18 months but investors are locked for 24 months, something is wrong. Founders should always have the longest vesting duration, reflecting their deepest commitment to the project.

5. Are treasury and ecosystem funds vested?

Treasury tokens that are immediately available to the team — even if labelled "ecosystem fund" — are functionally equivalent to unlocked founder tokens. A credible project vests or release-schedules every category of token, including DAO treasury. Ask for the treasury wallet address and verify its token release schedule.

6. Does the vesting contract have admin override functions?

Review the verified smart contract for functions like revoke(), setSchedule(), or any owner-only function that can modify vesting terms. A single-owner admin key that can modify or cancel vesting is a significant risk. A multi-sig (3-of-5 or higher) that can revoke unvested tokens upon confirmed departure is more acceptable — but the terms should be clearly disclosed.

Frequently Asked Questions