# Manage staking pools

### Pools list view

Go to **Staking → Pools** in the TMS admin app.

You’ll see an overview of all pools for your project, typically with columns like:

* **Pool name** – e.g. “MYT 30D Compound”, “MYT/USDT LP – 60D”.
* **Type** – Compound or Liquidity.
* **Status** – Upcoming, Active, Expired/Ended.
* **Lock period** – e.g. 30 days, 90 days.
* **APR / APY** – current configured rate.
* **TVL (Total Value Locked)** – total amount currently staked.
* **Participants** – number of wallets staked.
* **Rewards status** – funded / underfunded / depleted (wording may vary).

From this list you can:

* Click into a pool to view details and analytics.
* See at a glance:
  * Which pools are live and attracting TVL.
  * Which pools have ended.
  * Whether any pool looks **underfunded**.

***

### Understanding pool status

Each pool has one of several statuses:

#### Upcoming

* Start date is in the future.
* Users **cannot** stake yet.
* You can:
  * Review configuration.
  * Fund rewards (optional at this stage).
  * Adjust editable parameters (see next section).

#### Active

* Current time is between the start date and the end/expiration date.
* Users **can** stake (if you haven’t closed deposits) and earn rewards.
* You should:
  * Monitor TVL, APR/APY, and rewards status.
  * Ensure rewards are sufficiently funded to avoid onchain errors.

#### Expired / Ended

* Current time is past the end/expiration date.
* Usually:
  * No new stakes are accepted.
  * Users can **withdraw** their stake.
  * Reward accrual stops (depending on how the pool was designed).

Ended pools stay visible for:

* Transparency.
* Historical analytics.
* Allowing users to withdraw, if they haven’t yet.

***

### What you can adjust on a live pool

Not everything can be edited once the pool is deployed.\
Exactly which fields are editable can vary by deployment, but typically you can adjust:

#### Commonly editable

* **APR / APY**
  * You can increase or decrease the reward rate for future accrual.
  * This affects how quickly rewards are distributed from the pool’s balance.
* **End / expiration date**
  * You may extend a pool if you want it to run longer.
  * In some setups you may also move the end date earlier (shorten a campaign) – do this carefully and communicate clearly.
* **Pool caps**
  * Adjust total pool cap or per-user cap to better manage dilution or fairness.
* **Reward funding**
  * You can top up reward tokens if the pool is underfunded or if TVL is higher than expected.

#### Typically *not* editable

* **Pool type**
  * You cannot switch a pool from Compound to Liquidity or vice versa.
* **Staking token / LP pair**
  * Once deployed, the underlying asset is fixed.
* **Reward token**
  * If you need a different reward token, create a new pool.

When in doubt, open a pool in the admin app: editable fields will be clearly exposed; locked fields will be read-only.

***

### Funding and “Funds required”

After a pool is deployed, TMS shows you how many reward tokens it **needs** to fully run as configured.

You’ll see something like:

* **Funds required** – the total amount of reward tokens needed for the entire duration at the current APR/APY (based on assumptions).
* **Currently funded** – how much reward token you’ve actually deposited into the contract.
* **Status** – OK / Underfunded / Depleted (exact labels may differ).

#### How to fund / top up rewards

1. Open the pool in the admin app.
2. Look for the **reward funding** or **add rewards** section.
3. Enter how many reward tokens you want to deposit.
4. Sign the transaction from your Admin wallet.

You can repeat this as often as needed.

#### What happens if the pool is underfunded?

If the pool doesn’t have enough reward tokens:

* Users may still be able to stake and withdraw, but:
* Once the contract runs out of reward tokens, **reward-related transactions can revert** (onchain errors).
* Depending on implementation, users may see failed claim or interaction attempts.

Best practice:

* Keep an eye on the **reward status**.
* Top up rewards before they run out, especially if you’re actively promoting the pool.

If you decide you don’t want to add more rewards:

* Consider **ending** or **closing** the pool for new stakes.
* Communicate clearly to users that rewards are finished and they should withdraw.

***

### Controlling deposits and exits

You have operational levers to control how users enter and exit pools.

#### Close pool for new deposits

You can:

* Stop new stakes while still allowing:
  * Reward accrual for existing stakers (until end date), and/or
  * Withdrawals after lock periods.

Use this when:

* You hit your target TVL.
* You want to limit reward dilution.
* You’re planning a new version of the pool.

#### Handle post-lock withdrawals

For pools with a lock period:

* During the lock:
  * Users cannot withdraw.
* After the lock:
  * Users can withdraw their stake (and any rewards, depending on pool type).

Even after the pool has **Expired/Ended**, you typically keep withdrawals open indefinitely so users can recover their stake.

***

### Monitoring pool health

From the pool detail view, you can monitor:

* **TVL (Total Value Locked)**\
  Shows how much value the pool has attracted.
* **APR/APY vs reality**\
  Compare your configured rate to how rewards are actually being distributed (depending on your analytics).
* **Participants**\
  Number of stakers; helps gauge community adoption.
* **Rewards remaining**\
  Check if you’re close to depleting the reward balance.
* **Timeline**\
  Start date, lock period, and end/expiration date.

Healthy pools:

* Have consistent TVL relative to your expectations.
* Are properly funded for the remaining duration.
* Match what you’ve communicated to your community.

***

### Managing advanced features

If you use advanced staking features, manage them carefully:

#### NFT boost

* Review which pools have NFT boosts enabled.
* Make sure the NFT collection address and boost parameters are correct.
* Check that communication matches reality:
  * “Holders of NFT X get 2x rewards in pool Y.”

If you change or remove boost parameters, communicate clearly to avoid confusion.

#### Compound bounty

* Monitor how often harvests occur (i.e., when compounding is triggered).
* If compounding is too infrequent:
  * You may need to adjust the bounty or communicate to users that they can trigger it.

#### Management fee

* Check that any configured fees are:
  * Properly routed to your treasury/partner wallet.
  * Acceptable to your community given the APR/APY.

These features are powerful levers; use them intentionally, not just because they’re available.

***

### Troubleshooting common issues

#### “Users don’t see a pool in the staking portal”

Check:

* **Status** – Is the pool Active or Upcoming?
* **Start date** – Has the start date passed?
* **Visibility toggle** – Some deployments allow hiding pools; ensure it’s set to visible.
* **Network** – Users must be on the correct network in their wallet.

#### “Users see errors when claiming or interacting”

Likely causes:

* **Rewards depleted / underfunded**
  * Check reward token balance and “Funds required vs Funded”.
  * Top up rewards if needed.
* **Pool expired**
  * New rewards may no longer be generated; users may only be able to withdraw.
* **Wrong network**
  * Ensure users are on the same network as the pool.

#### “APR/APY looks wrong”

Check:

* TVL – A sudden influx of TVL may change effective yields.
* Reward funding – Underfunded pools may behave differently than expected.
* Pool configuration – Look for recent edits to APR/APY or end date.

If something is still unclear, test with a small stake from a controlled wallet and compare expected vs actual behavior.

***

### Best practices for operating staking pools

* **Review pools weekly**\
  Look at TVL, participants, rewards remaining, and any errors.
* **Avoid abrupt changes**\
  Changing APR or ending pools early is sometimes necessary, but always:
  * Announce changes in advance where possible.
  * Explain the reasons clearly.
* **Align pools with your messaging**\
  Don’t promise yields or lock durations that don’t match the pool configuration.
* **Keep a small test wallet**\
  Use it to validate behavior whenever you:
  * Create a new pool.
  * Change APR/APY or end dates.
  * Top up rewards.

Well-managed pools turn staking from a support headache into a **smooth, reliable engine** for long-term engagement.


---

# 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/staking-farms/manage-staking-pools.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.