# QuickSilver

## How does it work
The main functionality of Quicksilver is to allow users to transfer their assets to a network X, such that it is controlled by the Quicksilver Protocol, and in return, issue `qAsset` (derivative) tokens that represent that position. In this way users can get their staking rewards and use qAsset to perform any DeFi activity and generate additional yield at the same time.

The `qAsset` tokens constitute the user’s claim to their original native assets - plus net rewards earned over time - and must be burned at the point of redemption.

The `interchainstaking` module, for each onboarded chain, will generate and control a deposit account and a delegation bucket through the Interchain Accounts IBC module.

The purpose of the deposit account is to receive the transfer of liquid native assets. Upon receipt of a transfer into the deposit account, the corresponding address on the Quicksilver chain will be credited with the appropriate `qAsset` to the value of the transferred delegation shares.

The delegation shares are then transferred to the delegation bucket and redeemed back into a native delegated position so that the Quicksilver protocol receives the rewards pertaining to said delegation. At the end of each Epoch (3 days), the delegation bucket will redeem the rewards it has accrued, most of it will be restaked and the rest will be transfer to `feeCollectorPool`.

The goal of new QuickSilver's mechanism (Rebalance rate mechanism) is keepping ratio of asset/qAsset is alwasys equal to 1:1 so after each epoch, a mint/burn logic will be apply to rebalance the ratio.

One of the new concept of QuickSilver is Insurance Account, it means when qAsset was mint after each epoch then 5-10% of them will be sent to Insurance Account serve for Slashing mechanism.

## 1. Rebalance rate mechanism (Remove Redemtionrate):

**Step1**:
- Users can stake their ATOM tokens to CosmosHub though an ICA account, which is controlled by QuickSilver. In exchange, qAsset tokens will be issued and sent to the user. These qAsset tokens can be transferred to any Cosmos chain, but are most often used for DeFi activities on Osmosis.
[Reference Code](https://github.com/ingenuity-build/quicksilver-incognito/blob/ee5349ef0b123cd6ea4ed54769dd26c0717f7821/x/interchainstaking/keeper/receipt.go#L29)

**Step2**:
- When user claim their delegation reward, the qAsset rewards will be received. Following the old way with RedemptionRate, the rate will be updated this step. Our goal is make qAsset supply equal to delegated & unbonding native token on zone. [Reference Code](https://github.com/ingenuity-build/quicksilver/blob/develop/x/interchainstaking/keeper/keeper.go#L543)
- In this case, balance of native asset is higher than qAsset, then amount of qAsset will be minted to rebalance the ratio of asset/qAsset to 1:1.
- The 5-10% amount of qAsset above will be send to Insurance Account, and the rest will be distributed to qAsset holder (getted by **claim** module).
- qAsset will be distributed for qAsset holder, including the one who added liquidity and pool in Osmosis, Crescent, Sifchain
[Reference Code](https://github.com/ingenuity-build/quicksilver-incognito/blob/ee5349ef0b123cd6ea4ed54769dd26c0717f7821/x/participationrewards/keeper/rewards_holdings.go#L12)

## 2. Slashing mechanism:
- **Context**:
- When a user delegates asset to a not good validator, and in case that validator was slashing so a part of user's asset will be lost, it means the ration of asset/qAsset < 1. So we have to have a logic to burn qAsset in Insurance Account so rebalance the ratio.
- Quicksilver's team suggestion:
- The qAsset was minted will be burned intermediate (with amount equal to amount of Atom was slashed) instead of send to qAsset holder and Insurance account.
- Stop distribute qAsset for one or two epoch to satisfy the total amount of slash.
- With extremely situation where there's a big slashing and there's been a quite a significant disparity between, the foundation would have to buy qAsset of community pool, then transfer to Insurance Account to burn
- Notional's suggesttion:
- When the validator missing blocks, the protocol will (insofar as redelegation limitations permit) move the delegation to the validator that replaces it in the active validator set.

<!-- - Now, QuickSilver have a interface to keep track a lot of information of validators so when a validator is being jailed for a double-sign infraction or number of slash is over than a threshold, the protocol will (insofar as redelegation limitations permit) move the delegation to the validator that replaces it in the active validator set. -->
[Reference Code](https://github.com/ingenuity-build/quicksilver-incognito/blob/ee5349ef0b123cd6ea4ed54769dd26c0717f7821/x/interchainstaking/types/interchainstaking.pb.go#L667)

## 3. What next?
- In the couple weeks, Notional team will dive into Rebalance rate and Slashing mechanisms and cover the tests for this when we deal with the flows above.
- Notional team will implement unit/e2e test for QuickSilver, this is very important to be able to catch unnecessary bugs (QuickSilver is lacking a lot of them).
- Refactor code: the code of QuickSilver is good but in some cases it's still very difficult to understand, Notional team can cover this and make it more clear.