# How vesting strategies work

This page explains **how vesting strategies behave under the hood**: schedules, distribution types, revocable vs immutable, and what you can do at each stage of a strategy’s life.

Once you understand this, the UI will feel much more intuitive.

***

### Strategies & allocations

TMS separates **rules** from **recipients**:

* A **vesting strategy** defines *how* tokens unlock:
  * Start date / TGE date
  * Cliff
  * Total duration
  * Distribution type (linear, interval, monthly)
  * Initial unlock (TGE %)
  * Whether it can be cancelled (revocable) or locked (immutable)
* **Allocations** define *who* gets tokens under that strategy:
  * Wallet address
  * Allocation amount

Each strategy can contain many allocations. All of those allocations follow the **same schedule** defined by the strategy.

***

### Schedule building blocks

Every strategy is built from a few key elements.

#### Start date / TGE

The **start date** (often your TGE) is when vesting begins.

* It can be in the future (most common).
* It may include an **initial unlock** at the start (e.g. “10% at TGE”).

#### Cliff

The **cliff** is a period at the start of the schedule where **no tokens unlock** (except any initial unlock you explicitly set).

During the cliff:

* No vesting accrues.
* Users typically see “0 claimable” (beyond any initial unlock).

Once the cliff ends, vesting begins according to the distribution type.

#### Duration

The **duration** is how long it takes for the **entire allocation** to vest after the start/cliff.

Examples:

* 12 months
* 24 months
* 48 months

Together, **start date + cliff + duration** define the time window over which tokens move from “locked” to “vested”.

***

### Distribution types

TMS supports three vesting behaviors. You pick one per strategy.

#### Linear vesting

**Linear vesting** unlocks tokens **continuously** over time.

* Every second after the cliff contributes a tiny bit to the vested amount.
* Users can claim at any time once the cliff has passed.
* The amount they can claim depends only on:
  * How much time has elapsed, and
  * How much they’ve already claimed.

Use linear when you want the **smoothest possible unlock curve** with no visible jumps.

***

#### Interval vesting

**Interval vesting** unlocks tokens in **fixed chunks** every X days.

* You define an **interval in days** (e.g. 7, 10, 30).
* After the cliff:
  * No tokens vest until the first interval completes.
  * At each interval boundary, another chunk of tokens vests.

Example:

* Cliff: 2 months
* Duration: 12 months
* Interval: 10 days

Result (conceptually):

* No unlocks during the 2-month cliff.
* After the cliff, tokens unlock every 10 days in equal parts until the duration ends.

Use interval vesting when you want **step-wise unlocks** that are more frequent than monthly, but you don’t need second-by-second precision.

***

#### Monthly vesting

**Monthly vesting** unlocks tokens in **monthly intervals**.

* You define an **interval in months** (e.g. every 1 month, every 2 months).
* After the cliff:
  * The first unlock occurs after N months (depending on your configuration).
  * Subsequent unlocks happen every N months.

Use monthly vesting when you want unlocks to align with **calendar cycles** – e.g. investor updates, payroll, or regular reporting.

***

#### Initial unlock (TGE percentage)

For interval and monthly strategies, you can optionally set an **initial unlock** at the start.

Example:

* Allocation: 18,000 tokens
* Initial unlock: 10% → 1,800 tokens available at start
* Remaining: 16,200 tokens
* The remaining tokens vest over time according to the chosen type and interval.

This lets you express patterns like:

* “10% at TGE, then monthly for 12 months.”
* “25% at TGE, then every 2 months over a year.”

***

### Revocable vs immutable strategies

TMS distinguishes between **revocable** and **immutable** vesting strategies.

#### Revocable strategies

By default, a strategy is **revocable**:

* Before it starts, you can **edit everything**:
  * Distribution type (linear/interval/monthly)
  * Start date, cliff, duration
  * Initial unlock
  * Wallet allocations and amounts
* After it starts, the rules and allocations are fixed, but you can still:
  * Revocable = not locked; you can **disable/enable** (pause/resume) claims.
  * If you want to effectively “cancel”, you **disable and never re-enable**.

Revocable strategies give you flexibility while you’re still iterating or haven’t fully committed publicly.

#### Immutable strategies

A strategy becomes **immutable** when you **lock** it.

* Once locked:
  * You cannot change parameters.
  * You cannot change allocations.
  * You cannot cancel the strategy.

The schedule runs **exactly as configured**, enforced by the smart contract.

Immutable strategies are ideal when:

* You’ve fully validated the setup (ideally on testnet).
* Stakeholders know and rely on this schedule.
* You want a **strong trust signal** that no one (including Admins) can modify it.

A simple way to think about it:

> * **Revocable strategy** – You still have a kill switch (Cancel).
> * **Immutable strategy** – You’ve removed your own kill switch (Lock).

***

### Strategy lifecycle & what you can do when

Each strategy passes through a few clear states.

#### 1. Draft (before start time)

* The strategy’s start/cliff time is **in the future**.
* You can:
  * Edit **all** vesting terms.
  * Add, remove, or change wallet allocations.
  * Delete the strategy entirely if you don’t want to use it.

This is your **safe configuration phase**.

***

#### 2. Active (started, still revocable)

* Current time is **after** the start/cliff.
* Users may already be able to claim tokens according to the schedule.
* You **cannot**:
  * Change any vesting terms.
  * Edit wallet allocations.
* You **can**:
  * Monitor progress (vested, claimed, remaining).
  * **Cancel** the entire strategy (see “Cancelled” below).
  * **Lock** the strategy to make it immutable.

Use this state to run the strategy as planned, or to decide whether you want to **lock it** once you’re sure it’s correct.

***

#### 3. Locked (immutable)

* The strategy has been **locked by an Admin**.
* It is now **immutable**:
  * No edits, no allocation changes.
  * No cancel.

At this point, the strategy becomes a **purely onchain commitment**. It will complete exactly as configured.

***

#### 4. Enabled / Disabled

* An **Active** revocable strategy has been **Disabled**.
* Effects:
  * All future vesting stops.
  * All **unclaimed or still-locked tokens remain in the smart contract**.
  * Beneficiaries can **no longer claim anything** from this strategy, even if time passes.
* Once you **enable** the strategy, the system will begin vesting according to your strategy.

You cannot cancel:

* Strategies that are **locked (immutable)**.
* Strategies that were never started (you can just delete drafts instead).

***

#### Quick capability matrix

For reference:

| State              | Edit terms | Edit allocations | Disable/Enable | Lock strategy |
| ------------------ | ---------- | ---------------- | -------------- | ------------- |
| Draft              | ✅          | ✅                | n/a            | ❌             |
| Active (revocable) | ❌          | ❌                | ✅              | ✅             |
| Locked (immutable) | ❌          | ❌                | ✅ (pause UX)   | —             |

***

### How claims are calculated

For each wallet in a strategy, TMS continuously calculates:

1. **Total allocation** – the full amount assigned to that wallet.
2. **Total unlocked** – how much *should* be vested by now, based on:
   * The schedule (type, cliff, duration, intervals).
   * The current time.
3. **Already claimed** – how much the wallet has already claimed.
4. **Claimable now** = unlocked – already claimed.

Key points:

* If a user doesn’t claim for a while, **their vested amount accumulates**. They don’t lose tokens by waiting; they just end up claiming more at once.
* If the strategy is **Disabled and never re-enabled**, users can no longer claim further tokens. Unclaimed tokens remain in the contract.

This logic is the same across linear, interval, and monthly strategies; only the **shape of the unlock curve** changes.

***

### Choosing the right structure

As a quick guide:

* Use **Linear** when:
  * You want a smooth unlock curve.
  * You want to avoid large jumps in circulating supply.
* Use **Interval** when:
  * You want regular, chunked unlocks (e.g. every 7 or 10 days).
  * You’re okay with step-wise changes but want more granularity than monthly.
* Use **Monthly** when:
  * You want vesting to align with calendar expectations and reporting cycles.

And for revocability:

* Keep a strategy **revocable** (unlocked but not locked) while:
  * You’re still aligning internally.
  * You’re early and may need to react quickly.
* Make a strategy **immutable** (lock it) when:
  * You’ve double-checked all numbers and dates.
  * Stakeholders are informed and rely on this schedule.
  * You want maximum trust that no one can alter it later.

***

### What’s next?

Now that you understand how vesting strategies work, you’re ready to:

* **Create a vesting strategy** – configure your first real schedule and add allocations.
* **Manage strategies & wallet lookup** – learn how to monitor progress, handle support questions, and when (if ever) to cancel or lock.

Once those are in place, your Vesting & Claim Portal becomes the **operational backbone** of your token distributions.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://tms-finance.gitbook.io/tms.finance/vesting-and-lockups/how-vesting-strategies-work.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.