Vesting Contract

An initial lock-up period during which no tokens are released, even if a linear schedule is active. This is a common mechanism to ensure long-term commitment from team members or early investors before any distribution begins.

• Example: A 4-year vesting schedule with a 1-year cliff means the beneficiary receives 0 tokens for the first year, then a lump sum (e.g., 25% of the total) at the cliff's end, followed by regular releases.

The most common vesting model, where tokens are released continuously or in small, frequent increments (e.g., per second, per block, or per month) after any cliff period. This creates a smooth, predictable unlock curve.

• Mechanism: The contract calculates releasable amount as (total_amount * (current_time - start_time) / vesting_duration).
• Contrasts with bullet vesting, where the entire amount unlocks at a single future date.

Defines whether the grantor can cancel the vesting schedule and reclaim unvested tokens.

• Revocable Vesting: Common for employee equity; allows a company to reclaim unvested tokens if an employee leaves. Requires careful access control logic in the smart contract.
• Irrevocable Vesting: The schedule is immutable once initiated. This is typical for investor deals and public token sales, providing certainty to beneficiaries. The contract's ownership status is critical here.

The two primary actors in a vesting contract, each with distinct permissions.

• Beneficiary: The wallet address that receives the vested assets. Can typically only execute a release() or claim() function to withdraw available tokens.
• Grantor (or Owner): The address that creates the schedule and funds the contract. May have admin functions like revoking a schedule (if revocable) or changing the beneficiary, depending on the contract's design.

Contractual provisions that trigger the immediate vesting of some or all remaining tokens upon a specific event. These are encoded as conditional logic within the smart contract or an associated legal agreement.

• Single-trigger acceleration: Vests on a corporate event like an acquisition.
• Double-trigger acceleration: Requires two events, typically an acquisition followed by the beneficiary's termination, protecting them from being immediately dismissed post-merger.

A security feature where releasing vested tokens requires authorization from multiple private keys. This is often implemented by having the vesting contract hold tokens and requiring a multi-signature wallet or a DAO vote to approve the beneficiary's withdrawal request.

• Use Case: Used for treasury management or founder vesting to prevent unilateral access and ensure community or board oversight over large, scheduled unlocks.

Vesting contracts often require administrative functions (e.g., pausing, early release, revoking). The design of these privileges is critical.

• Single-point-of-failure: A single, externally-owned account (EOA) holding admin keys is a major risk.
• Multisig & Timelocks: Best practice is to use a multisig wallet (e.g., Safe) for admin control and a timelock (e.g., 48-72 hours) for any privileged action, allowing community oversight.
• Revocation Logic: The ability to revoke unvested tokens must be explicitly coded and its triggers (e.g., legal breach, termination) clearly defined to prevent arbitrary confiscation.

The vesting schedule defines how and when tokens become accessible, impacting security and user expectations.

• Cliff Period: A duration (e.g., 1 year) where no tokens vest. A sudden, large release post-cliff can cause market volatility. Smart contracts must correctly handle the timestamp logic for the cliff expiration.
• Vesting Slice: The frequency of releases (e.g., monthly, quarterly). More frequent, smaller slices reduce the impact of any single release but increase gas costs and contract calls. The contract must accurately calculate vested amounts for any point in time, avoiding rounding errors.

A core design decision is whether the vesting contract can be upgraded to fix bugs or adjust terms.

• Upgradable Contracts: Use proxy patterns (e.g., Transparent Proxy, UUPS). This allows patching vulnerabilities but introduces proxy risk and requires careful management of upgrade authority.
• Immutable Contracts: Once deployed, they cannot be changed. This is the most trust-minimized approach but means any bug is permanent, potentially locking funds forever. The choice depends on the required trust model and the maturity of the initial audit.

The vesting contract's interaction with the underlying token contract creates integration risks.

• ERC-20 Compliance: The contract must safely handle standard (and non-standard) ERC-20 behaviors, including tokens that charge fees on transfer or rebase.
• Allowance & Transfer Logic: The contract typically requires an upfront allowance. A flawed release function could fail if the token contract's balance or allowance checks are not properly respected.
• Tax/Regulatory Logic: Some designs incorporate KYC/AML gates or tax-withholding mechanisms. These add complexity and must be rigorously tested to avoid accidentally locking compliant users out of their funds.

Vesting releases on public blockchains are susceptible to timing and transaction-ordering attacks.

• Release Front-running: An attacker could monitor the mempool for a release transaction and front-run it with a transfer to change the recipient's address, potentially diverting funds.
• Gas Griefing: For contracts where the beneficiary must claim their vested tokens, an attacker could spam the network with high-gas transactions to make claiming economically unfeasible for the user. Designs should consider permissionless claims with gas cost mitigation or admin-assisted bulk claims.

Given the value locked and irreversible nature of bugs, vesting contracts demand extreme diligence.

• Comprehensive Unit Tests: Must cover all schedule edge cases (pre-cliff, post-cliff, between slices), admin functions, and failure modes.
• Formal Verification: For high-value schedules, mathematical proof of correctness for the vesting formula is recommended.
• Third-Party Audits: Essential. Auditors should focus on privilege escalation, math precision, timestamp manipulation, and integration risks with the specific token. A verified audit report from a reputable firm is a minimum standard for production use.

An initial lock-up period at the start of a vesting schedule during which no tokens are released. This is a common feature in employee and investor agreements to ensure commitment before any distribution begins.

• Purpose: Prevents immediate sell pressure and ensures participants remain engaged.
• Example: A 4-year vesting schedule with a 1-year cliff means the first 25% of tokens unlock after 12 months, with the remainder vesting linearly thereafter.

The most common vesting schedule, where tokens are released in equal, continuous increments over the vesting period.

• Mechanism: If 1,000 tokens vest over 1,000 days, 1 token is released per day.
• Use Case: Provides predictable, steady access to funds, commonly used for team allocations and advisor rewards to ensure consistent long-term alignment.

A broader term for any mechanism that prevents the transfer or sale of tokens for a specified period. A vesting contract is a specific, scheduled form of a lockup.

• Key Difference: A simple lockup is binary (tokens are completely locked or completely free), while vesting is a graduated release.
• Context: Exchange listings often require team token lockups post-TGE (Token Generation Event) to maintain market stability.

A fundamental smart contract primitive that delays the execution of a transaction until a specified future time or block. Vesting contracts are built on top of time-lock functionality.

• Core Function: Ensures immutability of the release schedule; not even the contract owner can accelerate it without a pre-programmed mechanism.
• Example: Ethereum's native TimelockController is a standard used by DAOs to secure governance actions, demonstrating the underlying technology.

A clause or event that causes tokens to vest faster than the original schedule, often triggered by specific conditions.

• Common Triggers: Company acquisition (change of control), achievement of a major milestone, or as part of a departure agreement.
• Mechanism: The smart contract contains logic to modify the vesting curve or release a bulk amount upon verifying the trigger condition.