# Canto Liquid Staking Module

## Introduction

B-Harvest suggests implementing a new module called `liquidstaking`, which has the following functionalities:

- Allows holders to earn staking rewards while still being able to trade or use their assets as needed.
- Holders of lsToken (issued as proof-of-stake for native tokens) take on near-zero risk due to insurance.

## Problem

Staking in a PoS(Proof-of-Stake) consensus mechanism allows individuals to participate in the blockchain network by committing a certain amount of tokens and contributing to the consensus process.

Stakers have the opportunity to earn rewards, but they must also follow the protocol rules (e.g. locking) and face potential penalties for malicious behavior. More specifically,

- When staking, the staked asset is locked and cannot be operated during the lock period.
- The risk of staking varies depending on which validator the user chooses.
- When a validator is double-signed slashed, the delegator immediately loses 5% of their staked assets.

## Suggested Solution

We can address these problems by ‘liquifying’ operational capacity. We propose a secure `liquidstaking` module that increases capital efficiency while avoiding slashing penalties. If any penalties occur, insurance will cover them.

The module is based on the following concepts: liquid staking, insurance, epoch

- Liquid staking makes staked assets that are locked as tradable
- Insurance removes the slashing risk that stakers take on when staking. Insurance makes secure liquidstaking mechanism possible.
- This module is epoch based module. It means that most of the core logic (trigger liquid unstake, trigger withdraw insurance, etc…) is done in epoch (not a realtime). An epoch is a predefined period of time which is longer than unbonding period.

### lsToken

A new token(lsToken) is minted as proof of staking the native token. lsToken will be circulated in the market instead of native token.

- Mint : lsTokens can be minted by liquid staking a chunk amount of the native tokens.
- Burn : Native tokens can be redeemed by burning specific amount of lsTokens equivalent to a chunk amount of the native tokens.
- Redeeming native tokens from lsToken will take
- Anyone with enough native tokens or lsTokens can mint or burn lsTokens

### Insurance

- **Why do we need this?**
- When delegators liquid-stake with validators, they share the risk of the validator being slashed.
- **Who provide insurance?**
- Insurance providers are capital investors who take insurance fee from lsToken holders.
- They take slashing risk from the validator they choose to protect such risk from lsToken holders.
- **What roles does it play in the module?**
- Insurance protects against the potential loss of funds from the slashing of staked tokens.
- The liquidstaking module necessitates that native tokens be covered by insurance, serving as a safety net for delegates.
- **What effect does it have?**
- In the past, delegators had to carefully choose a validator to avoid losing funds due to slashing. However, it is no longer necessary to choose a validator with such consideration, as it is now chosen by insurance.
- Delegators can exchange their lsTokens for native tokens at any time.

### Insurance fee rate competition

- **Why do we need this?**
- An insurance provider can charge fees freely to liquid staking users, which can decrease the return of staking.
- **What roles does it play in the module?**
- Ensure market competition mechanism in place to make insurance fee rate reasonable
- **What effect does it have?**
- User don’t have to worry about high insurance fees, as insurance policies with lower fees can participate in the liquid staking module. Insurances with higher fees have a lower chance of being selected.

### Dynamic Fee

- **Why do we need this?**
- A stable utilization ratio of the module helps the chain work more predictably and reliably.
- If the utilization ratio becomes very high(=too many native tokens are staked through `liquidstaking` module), it may result in validator power concentration

- **What roles does it play in the module?**
- Keep the chain running smoothly.
- **What effect does it have?**
- Limits validator power concentration.

**How it works**

- The fee rate is calculated as follows:
- **Utilization ratio(= *U*)** is calculated as follows: `chunkSize * numPairedChunks / totalSupply`
- **fee rate =** `R0` when *U* < *U_SoftCap*
- **fee rate =** `R0 + ((U - U_SoftCap) / (U_Optimal - U_SoftCap) x Slope1)` when *U_SoftCap* <= *U* <= *U_Optimal*
- **fee rate =** `R0 + Slope1 + ((min(U, U_HardCap) - U_Optimal) / (U_HardCap - U_Optimal) x Slope2)` when *U_Optimal* < *U* <= *U_HardCap*

Here are the default parameter values suggested.

| Param | Description | Default |
| --- | --- | --- |
| U_SoftCap | Softcap for utilization ratio. If U is below softcap, fee rate is R0 | 5% |
| U_HardCap | Hardcap for utilization ratio. U cannot bigger than hardcap. | 10% |
| U_Optimal | Optimal utilization ratio. | 9% |
| R0 | Minimum fee rate. | 0% |
| Slope1 | If the current utilization ratio is below optimal, the fee rate increases at a slow pace. | 10% |
| Slope2 | If the current utilization ratio is above optimal, the fee rate increases at a faster pace. | 40% |
| MaxFeeRate | Maximum fee rate. Fee rate cannot exceed this value. | 50% |

The above params always satisfy the following conditions:

- *0 ≤ U_SoftCap < U_Optimal < U_HardCap ≤ 1*
- *0 ≤ R0, 0 ≤ Slope1, 0 ≤ Slope2*
- *R0 + Slope1 + Slope2 ≤ MaxFeeRate*

### Discounted rewards

- **What is it?**
- A method for the module to sell accumulated staking rewards to arbitrageurs with small discount to work as a reward compounding functionality
- **Why do we need this?**
- Delegation rewards from liquid staking are accumulated in the reward module account which are not auto-compounded.
- This is a duck tape solution to auto-compounding; auto-compounding will be implemented after v1
- **What roles does it play in the module?**
- Make a similar effect to auto-compounding.
- **What effect does it have?**
- Cumulated rewards which have no utility can be consumed by lsTokens.
- This have similar effects with auto-compounding because lsTokens received will be burned.
- (math equation & graph to be inserted later)
- **How it works**
- Anyone who has lsTokens can withdraw rewards from the reward module account at a discounted price.
- **discount rate** = min(accumulated canto reward / chunk size in canto x num paired chunks), 3%)
- The discount rate increases linearly as staking rewards accumulate in the module account, up to a maximum of 3%.
- Arbitrageurs will withdraw rewards with a discount when the discount rate is profitable enough for them.

### Epoch

- **Why do we need this?**
- Implementing real-time based state transitions is complicated and time intensive. We’ve opted with epoch-based to launch fast without bringing substantial security risks.
- **What roles does it play in the module?**
- It helps to keep the system design as simple as possible.
- It helps to decrease the risk of unknown errors during operation. [Processing messages and core logic in real-time can increase the risk of errors due to the complexity of state transitions.](https://www.figma.com/file/s53fnwbWSd5kdWRmvskgqB/State-Diagrams-of-liquidstaking-module?type=whiteboard&node-id=0%3A1&t=wjgJwjhHwAMbip0F-1)
- **What effect does it have?**
- Less bug, less un-known risks.
- The main logic such as unstaking or withdraw insurance is processed on the epoch, so there may be a disadvantage of user requests not being processed immediately, but this design has security advantages.
- **How it works?**
- The duration of an epoch is the same as the unbonding period (=21 days).
- At every epoch period, most of complicate state transitions works.
- Details of which transitions happened will be shared later.