# How staking rewards work

### Core concepts: lock period, pool expiration, and status

Most pools share a few important concepts:

* **Lock period**
  * Number of days tokens must stay staked before they can be withdrawn.
  * During lock:
    * Users can’t withdraw (except in special emergency designs).
    * Rewards typically still accrue. 
* **Pool expiration date**
  * After this date:
    * Users can no longer **stake new tokens** in the pool. 
    * Existing stakers can usually still **withdraw**, and depending on configuration, may or may not continue earning rewards.
* **Active vs ended pool**
  * **Active**: Within the configured period where rewards are being distributed.
  * **Ended/Expired**: Pool no longer accepts new stakes; rewards typically stop accruing after the defined end/expiration logic.

Each pool type implements these slightly differently, but the pattern stays consistent.

***

### Compound pools – how rewards work

Compound pools use a **vault + underlying farm** pattern.

High level:

* Users deposit your token into a **Vault**.
* The Vault stakes everything into a **MasterChef**-style pool.
* Rewards are periodically harvested and **reinvested** into the Vault.
* Users hold a **proportional share** of the Vault balance, which grows over time. 

#### APR vs effective APY

When you configure a compound pool, you set a **target APR / APY** in the admin panel. 

Under the hood:

* The system continuously compounds rewards:
  * Rewards are calculated using the annual rate (APR/APY) over a 365-day cycle. 
  * When harvests occur, earned rewards are added back into the Vault.

Because rewards are **reinvested**, the effective return users experience is closer to **APY** (compounded yield), even if you input an APR.

You’ll typically see:

* Input: “12% APY” or similar in the pool config.
* Outcome: a compounding curve, not a straight line.

***

#### When does compounding happen?

Compounding (harvesting + reinvestment) happens when:

* A user **deposits**, **withdraws**, or **claims** in that pool, or
* Any user triggers a harvest via the **compound bounty** mechanism.

Each harvest:

1. Claims accumulated rewards from the underlying farm to the Vault.
2. Applies any **harvest fee** / bounty split.
3. Reinvests the remaining rewards into the Vault balance.

This increases the total Vault balance and, by extension, everyone’s share (in token terms).

***

#### Compound bounty (harvest incentive)

Harvesting requires an onchain transaction. To incentivize someone to pay that gas cost, TMS pools can be configured with a **compound bounty**.

Mechanics:

* When a user triggers a harvest:
  * A small percentage of harvested rewards is paid to **that user** as a bounty.
  * The rest is reinvested into the Vault for the benefit of all stakers.

This makes the system **self-maintaining**:

* No centralized cron job needed.
* Any user has an incentive to trigger compounding when it’s economically sensible.

***

#### Lock period in compound pools

For compound pools:

* The **lock period** defines how long a user must wait before they can withdraw their share. 
* During lock:
  * Users can deposit more.
  * Rewards keep accruing and compounding.
  * Withdrawals are blocked until the lock ends.

After the lock period:

* Users can **withdraw** their share of the Vault, including compounded rewards.
* If the pool is still within its active reward period (not expired), rewards may continue accruing until the pool expires. 

***

#### NFT boost in compound pools

If **NFT boost** is enabled on a compound pool:

* Users holding eligible NFTs receive a **multiplier** on their share of the pool’s rewards. 
* The boost is applied when:
  * Calculating the user’s reward claim or withdrawal.

Example (simplified):

* User’s normal share of compounded rewards: 100 tokens.
* They hold an NFT with a **2x multiplier**.
* Their boosted reward: 200 tokens.

This incentivizes NFT ownership and lets you tie **utility** to specific collections.

***

### Liquidity pools – how rewards work

In **liquidity pools**, users stake LP tokens from a DEX pair (e.g. TOKEN/ETH LP). 

Rewards are based on:

* The **amount of LP tokens** staked.
* The **duration** of the stake.
* The **pool’s reward rate / APY**. 

#### APY and reward rate

For LP pools, you configure:

* A target **APY%** in the admin panel. 

Under the hood:

* The contract uses your APY to determine a **reward rate** over time.
* Each user’s reward is proportional to:
  * Their LP stake
  * Divided by total staked LP
  * Multiplied by the reward rate and time staked. 

You don’t need to do the math manually; TMS handles it. You just choose an APY that fits your tokenomics and budget.

***

#### Lock period in liquidity pools

For LP pools:

* The **lock period cannot be 0** — rewards are only calculated for locked tokens. 
* During the lock:
  * Users cannot withdraw their LP tokens.
  * Rewards accrue based on their staked LP and the configured rate.

After the lock period:

* Users can **withdraw LP tokens** (provided any additional withdrawal conditions are met). 
* Reward accrual may:
  * Continue until pool expiration, or
  * Stop when you design it to (depending on the specific pool configuration).

Your docs should reflect your chosen behavior for each deployment (e.g. “rewards stop at expiration”).

***

#### NFT boost in liquidity pools

NFT boost also works for liquidity pools. 

* Users stake LP tokens as usual.
* If they hold an eligible NFT:
  * Their rewards receive a **percentage bonus** (e.g. +50%, +200%, etc.).
  * The base reward is computed normally, then the boost is applied.

Example:

* Base LP reward: 100 tokens.
* NFT boost: +50% (1.5x).
* Final reward: 150 tokens.

This allows you to combine **LP incentives** with **NFT utility** within a single system.

***

### Management fee (where enabled)

Some setups may include a **management fee** on staking rewards:

* Configured per pool.
* Applied as a small percentage on rewards or harvests.
* Paid out to:
  * Your project treasury, or
  * A partner address.

From a tokenomics perspective:

* Management fees can serve as **protocol revenue**.
* They can also be used for buybacks, development funding, or other long-term goals.

If you enable management fees, we recommend:

* Explaining this clearly in your docs and announcements.
* Ensuring your APR/APY is still attractive after fees.

***

### Putting it all together: a simple example

Imagine a compound pool with:

* 12% target APY
* 30-day lock period
* NFT boost enabled (2x for a specific NFT collection)

User A:

* Stakes 10,000 tokens.
* No NFT.

User B:

* Stakes 10,000 tokens.
* Holds an eligible NFT with a **2x multiplier**.

Over time:

* The Vault compounds rewards based on the 12% APY.
* Both users see their underlying vault share grow.
* When they claim/withdraw after the lock:
  * User A gets their normal compounded amount.
  * User B’s rewards are **multiplied** according to their NFT booster.

You configured all of this once; TMS and the contracts handle the rest.

***

### Design tips for staking rewards

A few practical guidelines:

* **Start conservatively.**\
  It’s easier to **add** new pools with higher rewards later than to slash APR/APY dramatically and damage trust.
* **Align lock periods with your roadmap.**\
  Don’t create lock periods that clash with major vesting unlocks or known volatility events.
* **Use NFT boost sparingly and intentionally.**\
  It’s powerful. Reserve it for collections or partners you really want to highlight.
* **Simulate scenarios before launch.**\
  Roughly model:
  * Expected TVL.
  * Reward budget over the pool duration.
  * Impact of management fees and bounty on net rewards.

Next step: once you’re comfortable with how rewards work, you’re ready to **create your first staking pool** and configure it to match your token strategy.


---

# 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/how-staking-rewards-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.