Hi Canto Community! This is Hyung from B-Harvest.
We are very excited to introduce innovated liquid staking module for Canto as below.
Please feel free to drop any comment.
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 be completed at the end of next epoch.
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 delegators.
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.
lsToken is now fungible because slashing risk from different validators is insured.
Users 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.
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.
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.
insurance provider provides insurance for slashing risk of specific validator, and earns fees.
the liquid staking protocol will choose validators to be staked on, who has lowest fee rate and enough insurance covered.
mm will supply lscanto to the market(AMM) by minting lscanto from the protocol by depositing canto tokens.
most end users will belong to 4. end users will just simply buy/sell lscanto on AMM, and this lscanto is not validator specific, but a single fungible token which accumulates canto staking rewards
The original motivation of this structure is to connect MEV marketplace with liquid staking.
It means that, if some validators are competitive at generating profit from MEV, then they will have more room to reduce validator fee rate to acquire more voting power, which will result in additional MEV profit for the validator.
Also, if some validators are trusted by insurance providers, it means that insurance providers can provide insurance coverage with lower fee rate because they trust such validator stronger. Hence naturally incentivize validators to accumulate stronger trust on security for the community.
So, with liquid staking, validator competition will become two dimensions: MEV capability and security trust. It allows natural competition marketplace for validators which result in competitive top validator formation.
This economic structure driven by Canto liquid staking module design will try a new innovative path towards significantly better solution for validator choice problem, compared to any other dPoS network in the world. And unlike other networks, this is executed not by every delegators, but by systemic way from the economic design and incentives within the model.
There will be arising questions about decentralization of validator group though. This is an area we should discuss together further. Right now, because maximum voting power from liquid staking will be limited to 25%, the impact is limited.
Really appreciate the explanation on how ls would work. I do have some follow up questions on this;
with the current status quo, those who are already staked/delegated to their canto to the validators set;
1a: given the disparity of voting power across active set (top 10) controls more than 2/3 of all voting power. how would this ls model solve the issue of decentralisation within the existing staked canto in the network. Especially when you’ll have both non liquid and liquid canto at launch.
1b: from my current understanding, this would only be applicable to those who hasn’t stake/delegate their canto to the network. Thus how would this address those who have their canto already staked; but want to convert their delegation to ls? is there an option for migration locked canto to lscanto at launch? what would be the mechanism like?
I would assume that this will go through a CIP once feedback period is over. With that being said; what’s the rough timeline to executing it ? (Best in weeks not particular dates.)
That’s my immediate questions… looking forward to your response.
1a: decentralization is not considered in liquid staking version 1.0. what i am expecting is that the protocol will choose validators with lowest fee rate. and top validators will hesitate to lower fee rate because they need to sacrifice more of their fee earnings than smaller validators. hence i expect that voting power from liquid staking will be acquired by smaller validators which will help decentralization. but this is my personal view and it is difficult to predict validator reactions.
1b : those who already have staked canto will need to unbond to buy lscanto. they will have enough incentive to unbond when there are significant liquidity incentives for lscanto pools, because lscanto pools will provide better APR than canto pools. migration feature is not provided but i don’t think it is critical.
CIP probably in next week. the implementation and internal audit will be finalized next week. however, we believe that because it is quite a large codebase(about 10k lines of code), audit might take about 2 months or even more. so approximately launch can happen early october.
some minor modification to the content and formula.
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 be completed at the end of next epoch.
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 delegators.
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.
lsToken is now fungible because slashing risk from different validators is insured.
Users 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: netAmount / 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.
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 / net amount), 3%)
The discount rate increases linearly as staking rewards accumulate in the module account, up to a maximum of 3% (this value is a governance parameter, default value: 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.
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.