Overview

Vesting smart contracts allows token issuers to lock and release tokens over time, helping to build trust with early investors and prevent sudden large-scale token sales by insiders. This mechanism is commonly used to manage team allocations, investor holdings, and other insider token distributions.

Fireblocks' Tokenization Engine supports creating and managing vesting schedules, enabling issuers to control token release timing, apply cliff periods, and handle cancellations when necessary.

Use cases

• Insider token lockups: Prevent large-scale token sales by locking team and investor tokens.
• Employee rewards: Issue tokens to team members with release schedules.
• Token launch stability: Stage the growth in token circulating supply to match market adoption, ensuring smoother price dynamics.

Primary features

• Token lockup with timed release: Lock tokens in a smart contract and release them incrementally.
• Vesting schedules: Define schedules with a cliff (no tokens released during this period) followed by linear token release.
  • Multiple periods allowed: Define schedules with multiple periods, each having their own cliff, followed by linear token release.
• Cancellable schedules: Allow admins to cancel, or uncancel, vesting rights (e.g., when an employee leaves).
  • When cancelled:
    • Vested tokens are sent to the beneficiary.
    • Unvested tokens are returned to the Forfeiture Admin (i.e. the account which triggered the cancellation).
• Immutable schedules: Vesting schedules cannot be updated once created (only cancelled if marked as cancellable when created).
• Non-upgradable contracts: The vesting smart contract is final and cannot be modified after deployment.

How vesting works

Cliff & linear release

A vesting period defines:

• startPeriod: When the vesting period begins.
• cliff: Duration before any tokens from this period become available.
• endPeriod: When this vesting period ends.

Each schedule can contain multiple periods with different parameters.

Example (cliff schedule)

Scenario:

• Tom’s allocation is 100k tokens
• John’s allocation is 50k tokens
• Vesting: 24 months total, with a 12-month cliff

Timeline:

• At 6 months: No tokens are available.
• At 12 months (cliff ends):
  • Tom can claim 50k tokens (50%).
  • John can claim 25k tokens (50%).
• At 18 months:
  • Tom can claim 75k tokens (75%).
  • John can claim 37.5k tokens (75%).

Quarterly vesting example

For 100k tokens, released quarterly for 2 years with a 1-year cliff:

• Cliff Schedule (first 12 months): 50k tokens locked
• Quarter 5: 12.5k tokens released at 12-15 months
• Quarter 6: 12.5k tokens released at 15-18 months
• Quarter 7: 12.5k tokens released at 18-21 months
• Quarter 8: 12.5k tokens released at 21-24 months

Roles & Permissions

DEFAULT_ADMIN_ROLE:

• Can Grant/revoke roles
• Cannot renounce their own admin role (prevents contract lockout)

VESTING_ADMIN_ROLE can:

• Create vesting schedules and start global vesting
• Release tokens on behalf of beneficiaries

FORFEITURE_ADMIN_ROLE can:

• Cancel vesting schedules

SALVAGE_ROLE can:

• Salvage tokens mistakenly sent to contract:
  • Salvage ERC20-compatible tokens (except for the vesting token itself)
  • Salvage ETH/gas from the contract

Deployment Flow

Prerequisites to successfully deploy the Vesting contract:

1. The vested ERC20 token must have a supply>0 value (it must have been minted, and its totalSupply() must return > 0).
2. Decide on a vesting mode: Global vesting mode (all schedules start relative to a global start time) or individual mode (absolute timestamps).
3. Select admin accounts: Choose vault accounts for Default Admin and Vesting Admin roles respectively.

Proceed to deploy the VestingVault contract with the token address, vesting mode, and admin addresses.

Usage Flow

1. Grant additional roles if needed (FORFEITURE_ADMIN_ROLE, SALVAGE_ROLE) (optional).
2. Transfer tokens to the contract to fund vesting schedules.
3. Create vesting schedules.

Limitations

• Fee-on-transfer tokens are not supported.
• Rebasing tokens are not supported.
• No “receipt” tokens (e.g., NFTs) are generated for vesting tokens.
• Beneficial rights to vesting tokens are non-transferable.
• Vesting schedules are not editable once created.
• No built-in functionality for limiting token minting on this contract, since the token has its own admin functions. We recommend removing the token’s MINTER and CONTRACT_ADMIN permissions if a maximum total supply is desired.