owned this note
owned this note
Published
Linked with GitHub
# YOU Staking Pool
Please note: This draft describes the YOU Staking Pool V3. It's implementation is subject to a DAO vote.
## Staking YOU tokens
Holders of YOU tokens, the youves governance tokens, can choose to stake their tokens. Staking means locking these tokens for a certain period of time. Staking YOU tokens comes with two benefits for the staking users:
- YOU stakes can participate in the youves governance process
- YOU stakes accrue platform rewards from fees and interest rate payments
## YOU Staking Pool V3 - Governance and Bailout pool for the youves Token
The YOU Staking Pool V3 supersedes its predecessor, the YOU Staking Pool V2, which was formerly known as the Unified Staking Pool. Unlike the V2 pool, which reduced rewards if a user unstaked within the first 180 days of staking, the V3 pool adopts a different approach to locking funds. Additionally, the V3 pool introduces an added bailout functionality, enhancing the platform's risk resilience.
### The Commitment
When users opt to stake their YOU tokens using the V3 contract, they **choose a cooldown period**. The Cooldown Period represents the duration during which their tokens **remain locked** after initiating a transaction to unstake them from the V3 pool. The cooldown period is a countdown that starts when the entrypoint `enter_cooldown`is called on the YOU Staking Contract V3. The maximum selectable lenght of the cooldown period is 32 epochs of 28 days each, in total 896 days or roughly 2.5 years. Users have the flexibility to select a cooldown period anywhere between 0 and a maximum 77'414'400 seconds (896 days).
**By choosing a cooldown period for their stakes, users commit their long term support to the platform**. Consequently, depending of the chosen cooldown period, users will receive more rewards and bigger vote weights than other stakers, who selected shorter cooldown periods. Users can have more than one stake and assign different cooldown periods to each of. A user could decide to stake half of the YOU tokens for a long term (eg 896 days), while choosing a shorter cooldown period for a second stake (eg 448 days).
### Factors influenced by the chosen Cooldown Period lenght
Since the cooldown period serves as a means to express the staker's **long term commitment** to the platform, the selected length of this the cooldown period significantly influences two aspects:
#### 1. The Paid Out Rewards
A user who chooses the maximum length of the cooldown period, receives the full amount of rewards his stake is entitled to. A user who selected 50% of the maximum cooldown period, will receive 50% of the rewards his stake is entitled to. This relation between cooldown period and rewards is linear.
#### 2. The Governance Vote Weight
A stake in the YOU staking contract also entitles the stake's owner to vote on governance decisions if they choose a cooldown period longer than 28 days (1 epoch). The voting power of the stake, or it's vote_weight, is determined by a) the chosen cooldown period and b) the size of the stake, including already accrued rewards or deducted bailouts. The bigger a users vote weight, the more his votes count in a youves governance vote.
A logaritmic curve is used to determine the vote weight of a stake, dependent of the chosen cooldown period. The longer the selected cooldown period, the bigger a user's vote weight.
The allocation of vote weight follows a binary logaritmic curve (log<sub>2</sub> n) which is segmented in 32 epochs of 28 days each. Each epoch has a certain vote weight assigned, derived from the logarithmic curve.
>tocheckiftrue
| cooldown period selected | assigned stake_weight factor | stake_weight percentage |
| -------- | -------- | ------ |
| 1 epoch (28 days) | 0 |0%|
| 2 epochs (56 days) | 1 |20%|
| 4 epochs (112 days) | 2 |40%|
| 8 epochs (224 days) | 3 |60%|
| 16 epochs (448 days) | 4 |80%|
| 32 epochs (896 days) | 5 |100%|
Mapped to 32 epochs, this results in the following `stake_weight` and `reward_weight` percentages per epoch, depending on the selected cooldown period:

*(click to enlarge)*
For the example user from above, who selected half of the maximum cooldown period as his commitment lenght, the stake_weight would be 4. This equals 80% of the maximum vote weight.
Users will be able to chose any cooldown period, but the smart contract will assign it to the epoch this cooldown period falls in.
In order to determine the the voting power of a stake, this `stake_weight` is applied to the users stake. A stakes voting power (number of votes) is calculated like this:
$$ votes = {(initialStake + accumulatedRewards - accumulatedBailouts) * voteWeightPercentage}$$
-------
-------
#### 1. The Reward Weight (expressed as `reward_weight`)
The `reward_weight` expresses a percentage of rewards to which a user is entitled, relative to the rewards they would receive if they selected the maximum length of the cooldown period.
When commiting a stake, the initial `reward_weight` of the stake is set as the following:
<br>
$$ rewardWeight = {selectedCooldownDuration \over maxCooldownDuration} * stakedAmount $$
<br>
Here's an example:<br><br>
$$ {38'707'200s \over 77'414'400s} * 1000 = 500$$ <br>
This user staked 1000 YOU tokens and selected half of the maximum cooldown period (38'707'200 seconds or 448 days) as commitment. Consequently, this stake's `reward_weight` is set to 500, which is 50% of the maximum possible reward weight for this fresh stake of 1000 YOUs. Same applies to this stake's `bailout_weight`, it's also set to 500.
In order to decide how much of the incoming rewards a stake is entitled to, the V3 contract compares the stake size of a single stake to the sum of all stakes and then applies the `reward_weight` to it in order to calculate the percentage of rewards that given stake in the pool is entitled to.
Depending on the size of the stake and the chosen cooldown period, the `reward_weight` will vary. The allocation follows a linear pattern: If a user selects the maximum cooldown period, their Reward Weight will encompass 100% of their pro rata rewards for the duration of their active stake. If the user opts for only 50% of the maximum cooldown period (roughly 448d), their `reward_weight` will constitute 50% of the possible maximum of rewards for this stahe. The rewards accumulated by a stake is directly proportional to the selected cooldown duration. The allocation of rewards per number of chosen epochs is linear.
On the new YOU staking contract a stake's Reward Weight is tracked as the `reward_weight`.
#### 2. The Governance Vote Weight (expressed as `stake_weight`)
Similar to the Reward Weight, the user's Governance Vote Weight will be determined which is expressed as , expressed as `stake_weight` on the contract. But instead of a linear distribution, a logaritmic curve is used to determine the vote weight of a stake, dependent of the chosen cooldown period. The longer the selected cooldown period, the bigger a user's vote weight. The bigger a users vote weight, the more his votes count in a youves governance vote.
The allocation of vote weight follows a binary logaritmic curve (log<sub>2</sub> n) which is segmented in 32 epochs of 28 days each. Each epoch has a certain vote weight assigned, derived from the logarithmic curve.
| cooldown period selected | assigned stake_weight factor | stake_weight percentage |
| -------- | -------- | ------ |
| 1 epoch (28 days) | 0 |0%|
| 2 epochs (56 days) | 1 |20%|
| 4 epochs (112 days) | 2 |40%|
| 8 epochs (224 days) | 3 |60%|
| 16 epochs (448 days) | 4 |80%|
| 32 epochs (896 days) | 5 |100%|
Mapped to 32 epochs, this results in the following `stake_weight` and `reward_weight` percentages per epoch, depending on the selected cooldown period:

*(click to enlarge)*
For the example user from above, who selected half of the maximum cooldown period as his commitment lenght, the stake_weight would be 4. This equals 80% of the maximum vote weight.
Users will be able to chose any cooldown period, but the smart contract will assign it to the epoch this cooldown period falls in.
In order to determine the the voting power of a stake, this `stake_weight` is applied to the users stake. A stakes voting power (number of votes) is calculated like this:
$$ votes = {(initialStake + accumulatedRewards - accumulatedBailouts) * voteWeightPercentage}$$
#### 3. The Bailout Weight (expressed as `bailout_weight`)
As the governance participants are also responsible to choose a strategy by voting for contract developments and contract parameter changes, they are also the ones who will be held accountable for decisions wich could lead to a bad debt situation. With great power comes great responsibility.
This responsibility comes in the form of the Bailout Weight (`bailout_weight`) which defines the relative size of a users share to cover a bailout of a bad debt position. The longer the selected Cooldown Period, the bigger the Bailout Weight of that stake. Or in other words, the more influence a stake has on a vote, the bigger the stake's commitment to contribute to a bailout of bad debt.
The Bailout Weight is stored in the `bailout_weight` value of a stake.
#### What Bailout?
Let's have a brief look at a possible bad debt scenario in order to understand what could lead to a bailout:
Let's assume the governance participants decide to set very low collateralization parameters for minters on a certain engine or smart contract. In an event, where the collateral of a vault would rapidly and massively devalue against the minted synthetic asset, it might become unprofitable for liquidators to liquidate a undercollaterlized vault: they could get less collateral value out, than they need to provide synthetic asset value to reduce the minter's outstanding debt.
A vault which is undercollateralized, but won't be liquidated, can be characterized as **bad debt**. If bad debt stays unresolved on the platform for a longer time, it will have direct consequences on the peg of the synthetic asset in which bad debt exists. The synthetic asset will devalue against the asset it tracks, essentially impacting the platforms stability in a negative way.
Since it's existence, the youves platform has never seen a bad debt situation, mainly due to the currently set safe minimum collateralization ratios for more volatile assets. Nevertheless, in order to make the platform more attractive for traders/minters, it might be necessary to lower the collateralization ratio in the future. The community of YOU stakers, which is the governing body of the youves platform, has to decide to what extent this should be done. And because stakers decide about this risk factor, they should also be the ones paying for a bailout, if the platform ever accrues bad debt.
The bailout mechanism itself will be covered seperately, further down in this article.
### Parameter change during the Cooldown period
When a user calls `enter_cooldown` for a stake, the selected cooldown period starts for that stake. During the cooldown period, two of the above parameters will change:
#### Reward Weight is halved
When the cooldown period starts, the Reward Weight (`reward_weight`) associated with a user's stake is set to 50% of its preceding value. This adjustment persists until the cooldown period ends, at which point the user becomes eligible to claim their rewards. These rewards encompass the gains accumulated by their stake during both the initial staking period and the subsequent cooldown period.
#### Governance Vote Weight remains the same
A user who triggered the cooldown period on a stake, will still be able to vote with that stake at the same stake_weight as before. Note, that a user cannot trigger cooldown while his stake is locked in the governance contract (eg. during the voting phase of a YIP).
#### Bailout Weight remains the same
In contrast to the Reward Weight, the Bailout Weight stays the same during the cooldown period. This is mainly to ensure that stakers won't just trigger the cooldown period due to an upcoming bailout.
#### Recommitting during a cooldown
Once a cooldown period on a stake has started and is running, a user can always recommit the stake and reenter the pool. The previously selected cooldown period of this stake will be resetted. Consequently, the `reward_weight` will be set back to it's previous value.
### After the Cooldown period
#### Withdrawing the stake
Once the cooldown period ended, the stake continues to earn rewards as if it still was in the cooldown, but a user can and should withdraw his stake now. By withdrawing, the user will recover the amount of YOU he is currently entitled to. In order to calculate a users stake, the contract calculates the following:
$$ withdrawalAmount = {initialStake + accumulatedRewards - accumulatedBailouts}$$
Users should be aware that accumulated bailouts will lower the withdrawal amount, while accumulated rewards will increase the withdrawal amount.
Users need to withdraw their stake within the timespan defined in `max_withdraw_delay`, otherwise the risk to loose a part of their stake and rewards:
#### Kickout
After the cooldown period ran out, a user needs to withdraw his stake within the timespan specified in `max_withdraw_delay`. If the user doesn't withdraw his stake within that timeframe, other users can kick the stake out, by calling the `kickout` entrypoint and providing the stake's ID. Upon kickout the user's tokens from the stake, including the accumulated rewards minus the acumulated bailouts, will be transferred back to the original stake owner, as if it was withdrawn, but the user initiating the kickout will receive a reward that consists of a percetage of the affected stake's accumulated rewards, as defined in `kicker_reward_ratio`.
This means users need to observe the cooldown period and withdraw actively in order to retain the full balance of the stake and it's rewards. Otherwise the kicker will receive the defined percentage of the accumulated rewards of the kicked out stake.
### The Bailout process
In the case the platform accrues bad debt, as outlined above, anyone can propose a bailout via a youves governance vote. Therefore, the new V3 pool comes with a `bailout` entrypoint that accepts a lambda. This way, the pool allows for several ways a bailout could happen.
Let's dive into a possible bailout scenario to illustrate how the bailout could be used: A vault in the uUSD with tez collateral has accrued bad debt and is in a state where liquidation is not profitable anymore. We assume that no liquidator would liquidate this vault under the current circumstances. Youves contributors can now create a governance proposal with a lambda that would call the `bailout` entrypoint submitting a lambda which would:
1. claim some of the YOU tokens in the unified staking pool
2. swap them to uUSD
3. liquidates the undercollaterlized vault
4. swaps the received tez to YOU tokens
5. returns the remaining you tokens to the YOU staking pool
As the V3 Staking Pool allows to have multiple administrators, the youves keyholders could retain administrative rights at the beginning. This would allow the keyholders to enforce a bailout at any time, even if the YOU stakers voted against it. Of course, such an overruling of a governance vote would essentially turn governance itself into a farce, but it is important to know that the possibility exists. The community could still decide to remove the keyholders from the list of admins.
## DAO Contract V2
The YOU Staking Contract V3 is deployed with a specific DAO contract.