Please note: This is a draft of an upcoming Youves Improvement Proposal (YIP) created by youves core contributors. The YIP would introduce a new YOU Staking Pool, the YOU Staking Pool V3, and a adapted DAO contract.
Contract development, audits and testing will soon be concluded.
The deployed contracts and necessary lambdas will be published later in this same post. This preliminary draft intends to inform the community about the proposal and to invite everyone to comment.
YOU Staking Pool V3 - Governance and Bailout pool for the youves Token
The YOU Staking Pool V3 supersedes the YOU Staking Pool V2, previously known as the Unified Staking Pool. The new V3 Staking Pool introduces new features that are crucial for the advancement of the youves platform as laid out in the Strategic Vision blog post.
The proposed V3 pool comes the following changes:
The Commitment
When users opt to stake their YOU tokens using the V3 contract, they will have to 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 maximum selectable lenght of the cooldown period is 32 epochs of 28 days each, in total 896 days. Users have the flexibility to select a cooldown period anywhere between 0 and a maximum 77’414’400 seconds (896 days).
The cooldown period starts when the entrypoint enter_cooldown
is called on the YOU Staking Contract V3.
By staking YOU, users commit their long term support to the platform. Consequently, depending of the chosen cooldown period, they will receive more rewards and bigger vote weights than other stakers, who selected shorter cooldown periods.
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 three crucial factors or weights:
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:
Here’s an example:
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 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. But instead of a linear distribution, it uses a logaritmic curve to determine the the vote weight, expressed as stake_weight
, dependent of the chosen commitment lenght (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 (log2 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% |
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 had he chosen the maximum commitment time of 32 epochs.
Users will be able to chose any cooldown period, but the smart contract will assign it to the number of epochs 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. So the stakes voting power (it’s votes) are calculated like this:
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 od 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.
Why Bailout? Possible Bad Debt Scenarios
Let’s have a brief look at a possible bad debt scenario in order to understand what could lead to a necessary 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, 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, especially 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.
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:
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:
- claim some of the YOU tokens in the unified staking pool
- swap them to uUSD
- liquidates the undercollaterlized vault
- swaps the received tez to YOU tokens
- 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 will also need an adpated DAO contract to be deployed in order to process the new vote weights. This mainly because the current DAO contract has no entrypoint to change the The migration to this new DAO contract will be an integral part of this YIP. The general functionality of the DAO will not be changed.
Next Steps
The youves core contributors invite you to comment on this upcoming proposal. It it expected that an on-chain proposal will be submitted in the next days.