# Manage vesting strategies

This page explains how to work with vesting strategies **after** they’ve been created:\
how to read the strategy list, what you can do in each state, when to lock, when to disable, and how to use wallet lookup to support your users.

***

### Strategy list view

Go to **Vesting → Strategies** in the TMS admin app.

You’ll see a list of all vesting strategies for this project, typically with columns like:

* **Name** – e.g. “Seed Round”, “Team 4-Year”.
* **Category** – Team, Investors, Advisors, Community, etc.
* **Distribution type** – Linear, Interval, Monthly.
* **Network** – The chain this strategy lives on.
* **Status** – Draft, Active, or Locked.
* **Total allocated** – Sum of all allocations in this strategy.
* **Vested / claimed** – Progress over time.

From this view you can:

* Open a strategy to see details and actions.
* Quickly see which strategies are still in setup (Draft), which are live (Active), and which are fully committed (Locked).

***

### What you can do in each state

Each strategy has a **state** that controls what you can and cannot do.

At a high level:

* **Draft** – Before start time; fully editable.
* **Active** – Vesting has started; terms are fixed.
* **Locked** – Immutable; schedule and allocations can never change.

Separately, a strategy can be **Enabled** (users can claim) or **Disabled** (claims paused).\
Think of Enable/Disable as a **pause/play** switch for claims.

#### Draft

A Draft strategy has a start/cliff time in the future and vesting has not begun.

You can:

* Edit **all schedule parameters**:
  * Start date / TGE date
  * Cliff
  * Duration
  * Distribution type (linear, interval, monthly)
  * Initial unlock (TGE %)
* Edit **allocations**:
  * Add wallets
  * Remove wallets
  * Change allocation amounts
* Change **name and category**.
* Delete the strategy if you decide not to use it.

Use Draft state to finalize your setup and fix any mistakes **before** vesting starts.

***

#### Active (started, not locked)

An Active strategy has passed its start/cliff time and vesting has begun.

In this state:

* You **cannot**:
  * Change schedule parameters (dates, durations, type, percentages).
  * Add/remove/change wallet allocations.
* You **can**:
  * View progress (vested vs vesting, claimed vs unclaimed).
  * **Enable/Disable** the strategy:
    * **Enabled** → users can claim normally.
    * **Disabled** → users cannot claim from this strategy (claims are paused).
  * **Lock** the strategy to make it immutable.

Use Active state to:

* Monitor real-world behavior.
* Decide when to **lock** a strategy once you’re sure it’s correct.
* Temporarily **disable** claims if there’s an issue or you need to pause activity.

***

#### Locked (immutable)

A Locked strategy has been explicitly marked **immutable** by an Admin.

In this state:

* You **cannot**:
  * Edit schedule parameters.
  * Edit wallet allocations.
* You **can**:
  * View all data (allocations, progress, claims).
  * **Enable/Disable** the strategy:
    * Disabling will pause claims but does **not** change the schedule or allocations.

Locking is a **strong commitment**:

* The vesting rules and allocations are fixed forever.
* Even Admins cannot change them.

You still retain the ability to temporarily **disable claims** (for example, if there’s a security incident and you need to pause user interactions), but the underlying vesting logic cannot be altered.

***

#### Enable vs Disable (pause/resume)

Enable/Disable is **independent** of Active vs Locked. It controls whether users can **claim**, not whether vesting progresses.

* **Enabled**
  * Users can interact with the strategy through the Vesting & Claim Portal.
  * They can see balances and perform claim transactions.
* **Disabled**
  * Users **cannot** claim from this strategy.
  * The vesting schedule still moves forward in time.
  * When you re-enable, all tokens that *should* have vested while it was disabled become claimable again.

If you want to **effectively terminate** a strategy:

> Disable it and do not re-enable it.\
> Users will no longer be able to claim; unclaimed tokens remain in the contract.

This behaves like a “soft cancel” while preserving data for audit and history.

***

### When (and why) to lock a strategy

Locking a strategy makes it **immutable**: rules and allocations can never change.

Good reasons to lock:

* It’s a **major schedule** (e.g. Team, Seed, Private) that investors or regulators expect to be fixed.
* You’ve already:
  * Tested a similar setup on testnet.
  * Double-checked all dates, cliffs, durations, and totals.
  * Verified allocations and sample wallets.

Once locked:

* You can communicate to stakeholders:

  > “This vesting schedule cannot be changed, even by us.”
* You can still **Enable/Disable** claims as an operational safety valve, but you cannot alter the underlying commitment.

Locking is how you turn a strategy from “configurable” into **pure onchain credibly-neutral behavior**.

***

### When (and why) to disable a strategy

Disabling a strategy **pauses claims**. Users cannot claim from that strategy while it’s disabled.

Common reasons to disable:

* You discovered a **serious issue** and want to stop claims while you assess.
* You’re in the middle of a **migration** or technical maintenance.
* You need to temporarily halt claims due to:
  * a security incident,
  * a legal/regulatory change, or
  * a discrepancy you’re investigating.

When you disable:

* The vesting schedule continues in the background; tokens continue to unlock.
* Users simply can’t pull those tokens out while it’s disabled.
* When you re-enable, all vested-but-unclaimed tokens become claimable again.

If you intend to **shut down a vesting program permanently**:

1. Disable the strategy.
2. Communicate clearly to affected users/investors.
3. Optionally create a **new strategy** to replace it with updated terms.
4. Leave the old strategy **disabled forever** to keep its data for historical reference.

This is the closest equivalent to “cancelling” a strategy in this model.

***

### Common operational patterns

A few real-world patterns using these tools:

#### Before starting (Upcoming)

* Add or adjust investors, advisors, or team wallets.
* Correct allocations that came in wrong from spreadsheets.
* Adjust the schedule (dates, cliffs, durations) while it’s still painless.

#### Right after start (Active, Enabled)

* Monitor early claims to confirm behavior.
* Use wallet lookup for the first batch of “How do I claim?” questions.
* Decide when you’re comfortable **locking** long-term strategies.

#### After validation (Locked, Enabled)

* Lock key strategies once validated and communicated.
* Let vesting run on autopilot; your main task becomes monitoring, not managing.
* Use wallet lookup to support users and provide investor updates.

#### Emergency or major change (Active or Locked, Disabled)

* If you discover a serious issue or need to pause:
  1. **Disable** the affected strategy to immediately stop claims.
  2. Investigate and decide:
     * Re-enable once resolved, **or**
     * Keep it disabled permanently and replace it with new, correct strategies.
  3. Communicate clearly with your community/investors about what’s happening and why.

***

### Best practices

* **Do as much as possible in Upcoming /** **Draft.**\
  Fixing things before start is always cheaper (and less stressful) than doing it after.
* **Use testnet whenever in doubt.**\
  Mirror your mainnet setup on a testnet environment and rehearse claims before going live.
* **Lock with intention.**\
  Only lock strategies once they’ve been reviewed and communicated; it’s a one-way door.
* **Treat Disable as a serious lever.**\
  It’s your emergency brake. Use it thoughtfully, and always pair it with clear communication.
* **Use wallet lookup instead of guessing.**\
  Any time a user reports an issue, start with wallet lookup to see the exact state of their allocations and claims.


---

# 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/manage-vesting-strategies.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.