---
# System prepended metadata

title: Bailout & DAO Migration - internal

---

# Bailout & DAO Migration

## Summary

In the the strategic vision (outlined here: https://medium.com/@youves/shoot-for-the-stars-with-youves-our-strategic-vision-%EF%B8%8F-552635fd4603), the transformation of the YOU Staking pool is a central piece. This transformation aims to:

- reward those who are willing to put funds at stake for the platform, with bigger rewards and bigger influence (vote weight), the longer they are willing to stake and support youves
- transform the YOU staking pool into the buyer of last resort for potential bad debt in regard to the future trading capabilities
- split-off the buyback functionality from the YOU staking contract

After intense development, testing and an audit, conducted by [Inference AG ](https://inference.ag/), the new YOU staking contract is ready to be used.

This article highlights the proposed migration path from the current YOU Staking Pool contract (aka *Unified Staking Pool* / `KT1UZcNDxTdkn33Xx5HRkqQoZedc3mEs11yV`) and it's DAO contract to the new YOU Staking Pool contract (aka *Commitment Pool* or *Bailout Pool* / `KT1KZFR9Qu2FtYQmWNnXoef3d3ULQPvxqnEW`) and it's new DAO contract. 

This migration involves a YIP vote using the old DAO, youves multisig keyholder actions, user interaction and a cleanup phase, as well as a second YIP to replace the historically grown buyback structure. 

The distinctive phases of this migration are outlined below:

## New Contract Deployment Phase


#### 1. Deploy new bailout pool on mainnet
A new contract for the new YOU staking pool aka *Bailout Pool* has already been deployed on December 29, 2023 on mainnet: [`KT1KZFR9Qu2FtYQmWNnXoef3d3ULQPvxqnEW`](https://better-call.dev/mainnet/KT1KZFR9Qu2FtYQmWNnXoef3d3ULQPvxqnEW/storage). This new YOU staking pool has the features and functionalities outlined here:

- https://docs.youves.com/governance/YOU-Token-Staking

It's security audit by Inference AG is finalized and will be published here, shortly:

- https://github.com/InferenceAG/ReportPublications

Smart contract code is published here:

- https://github.com/youves-com/youves-smart-contract/blob/main/contracts/tracker/commitment_pool_v2.py

The following parameters were set upon deployment:

- `epoch_lenght`: 2'419'200 seconds (28 days), lenght of an epoch
- `max_cooldown_duration`: 77'414'400 (896 days), maximum selectable cooldown lenght
- `max_withdraw_delay`: 7 days, during which a cold stake is protected from being kicked
- `kicker_reward_ratio`: 10%, of a stake's rewards which go to the kicker (if the stake was not withdrawn within 7 days after cooldown)
- `voting_scale_map`: a map of 32 epochs of 28 days assigned along a log<sub>2</sub> curve (see documentation) used to determine a stake's vote weight depending on the selected cooldown period lenght
- `token_address` and `token_id`: KT1Xobej4mc6XgEjDoJoHtTKgbD1ELMvcQuL:0, the YOU token



#### 2. Deploy new DAO on mainnet

Additionally a new instance of the DAO contract [`KT1F2QfNnYQi7XQTa68ZZfpFgyKzS4vJpBaK`](https://better-call.dev/mainnet/KT1F2QfNnYQi7XQTa68ZZfpFgyKzS4vJpBaK/storage) has been deployed. 

This new DAO contract has the following settings which differ from the existing DAO contract:

- `voting_contract`: `KT1KZFR9Qu2FtYQmWNnXoef3d3ULQPvxqnEW`, the new YOU staking contract (stakes from the new YOU staking pool will be allowed to vote on the new DAO contract).
- `break_glass_contract`: the youves multisig contract `KT1Q8yKdJaU5VcBL8JcxUT9PU99m53ubERk4` is allowed to act as break glass guardian (as today)
- `community_fund_address`: the new YOU staking contract, will receive any kept back escrow funds
- `quorum`: Start quorum will be set to 500'000 YOU, roughly 1/3 of the current DAO's quorum
- `quorum_cap`: The `lower` quorum cap will be set to 250'000 YOU, the `upper` quorum cap will be set to the same as in the old DAO: 3'744'000 YOU

All other parameters remain the same like on the current DAO contract (`KT1C3T98TqCm38cHPauZ4SopkQ4torCsxgab`)

The cooldown period of a stake defines its `vote_weight` and the number of votes a stake is entitked to. Because it cannot be predicted how YOU stakers will decide to choose cooldown periods for their stakes, the total number of votes available after migration cannot be predicted. If a majority of YOU stakers decide to stake short term, the number of available votes would be drastically decreased compared to the number of votes assigned to stakes today. 

It is expected that YOU stakers will choose a mix of long term and short term stakes in order to keep flexibility while optimising for reward and vote weight. This will already lead to a decreased number of votes, compared to the pervious YOU staking pool.

In order to mitigate the risk of not being able to reach a quorum for several voting cycles, the proposal lowers the quorum from currently 1'472'749 to 500'000, roughly 1/3 of the current quorum. Similarly, the lower quorum cap is proposed to be lowered from currently 800'000 to 250'000.


## YIP Phase One

Next, a YIP will be submitted for vote to the stakers of the existing unified staking contract, asking to set the new DAO contract as admin on all youves contracts which allow for only one administrator. Only the DAO can replace itself on these contracts.

Additionally, the YIP will ask to set down the `max_release_period` on the existing YOU staking pool to 1 second. This will allow stakers after the vote to remove their stakes without losing out on rewards in order to move their stakes to the new YOU staking pool.

Finally the YIP will include a change of the lower and upper quorum caps on the old DAO to levels which can never be reached. This will ensure the old DAO cannot be used by a minority to abuse it's administrator power during the migration.

#### First YIP: propose the new DAO as admin on all 1-admin contacts

- Propose the new DAO as admin on all flat curves dex contracts
- Propose the new DAO as admin on the cCHF checker contract
- Propose to set `max_release_period` on the existing YOU staking pool to 1 second
- Propose to set lower and upper quorum cap to a minimum of 5 million YOU tokens, an amount that cannot exist
   
Affected contracts are all flat curve contracts + checker cchf:

| contract | what | set admin | proposed admin | set reward recipient |
| -------- | ---- | --------- |--------------------- | ------------------------ |
|KT1JeWiS8j1kic4PHx7aTnEr9p4xVtJNzk5b|wusdcuusd|yes|yes|yes|
|KT1AVbWyM8E7DptyBCu4B5J5B7Nswkq7Skc6|kusduusd|yes|yes|yes|
|KT1Xbx9pykNd38zag4yZvnmdSNBknmCETvQV|usdtzuusd|yes|yes|yes|
|KT1XvH5f2ja2jzdDbv6rxPmecZFU7s3obquN|ubtctzbtc|yes|yes|yes|
|KT1T974a8qau4xP3RAAWPYCZM9xtwU9FLjPS|tzbtcwwbtc|yes|yes|yes|
|KT1UJBvm4hv11Uvu6r4c8zE5K2EfmwiRVgsm|usdtuusd|yes|yes|yes|
|KT1NgbaaYhtXh3MwJoYYxrrKUwG3RX5LYVL6|usdceuusd|yes|yes|yes|
|KT1CkpDuwCFrnoqTam6upYiPBiFNsSEVbBei|ubtcwbtce|yes|yes|yes|
|KT1WgguedKZWucrdRKQXaRECEPMZennaVPck|uxtztez|yes|yes|yes <sup>r</sup>|
|KT1BFXgczFte2zftCTg7tL6Qk2capsFg6UFS|uxtztezV2|yes|yes|yes|
|KT1SPUvH5khHtirTEVeECiKrnh4FFXxWZ6ui|uxtztezV3|yes|yes|yes|
|KT1Ad5yJzoiRRdMJPvhJiPJ7Cq8WbJnCS7bg|uxauuusd|yes|yes|yes|
|KT1STLQKxiRtAh1e7DZhu1xUTAJ7KLpV9Rru|ubtcuusd|yes|yes|yes|
|KT1LrEJsaTR5vMdwjvASTtFPUbk2wnX3P166|checkercchf|yes|no|yes|
    
<sup>r</sup> reward recipient is old reward collector proxy, should be set to either newest or KT...Wixo



## Migration phase
    
Once the new DAO is set as admin in all contracts stakers can withdraw their YOU token stake and migrate them to the new YOU staking pool. The frontent will be redoployed with the new DAO and YOU staking contract. Users will be askd to withdraw their stakes and create new ones on the new YOU staking contract.
    
#### Move stakers to the new bailout pool

- deploy frontend for new bailout pool / DAO
- inform all you stakers to withdraw their YOU tokens    
- ask all YOu token holders to create new stakes on the new YOU staking contract

## YIP 2 Phase Two

Once a majority of YOU stakers migrated from the old YOU Staking pool to the new YOU Staking pool, a second YIP will be conducted in order to accept the administratorship of the new DAO on the single-admin contracts. Only then the new DAO will be admin on the old contract.

#### Accept admin proposal via new DAO

- submit a YIP on the new DAO to accept administratorship on the single-admin contracts 


## Multisig Operations Phase

In order to avoid numerous YIPs to set all contract admins, the youves multisig contract, which is still admin together with the DAO on all multi-admin contracts, will be used to set the new DAO as admin and as the interest rate setter and to remove the old DAO as admin. These includes all synthetic asset engines, including legacy engines, as well as savings pools, farms, the stake manager, reward collector v2.

#### Set new DAO as admin on all multi-admin contracts, remove old DAO from admin

- set new DAO as admin on all multi-admin contracts - youves multisig
- set new DAO as interest rate setter contract - youves multisig
- set new DAO as admin on the stake manager contract (KT1...XSz4) - youves multisig

Affected contracts:

Engines:

| contract | what | set admin | set reward recipient | set int rate setter |
| -------- | ---- | --------- |--------------------- | ------------------------ |
|KT1FFE2LC5JpVakVjHm5mM36QVp2p3ZzH4hH|uusdtezV1<sup>l</sup>  | yes     | yes<sup>1</sup> |no|
|KT1HxgqnVjGy7KsSUTEsQ6LgpD5iKSGu7QpA|uusdtzbtcV2<sup>l</sup>|yes      | yes<sup>1</sup> |no|
|KT1FzcHaNhmpdYPNTgfb8frYXx7B5pvVyowu|uusdsirsV1<sup>l</sup>|yes      |yes<sup>1</sup>  |no|
|KT1JmfujyCYTw5krfu9bSn7YbLYuz2VbNaje|uusdusdtV3|yes|yes<sup>2</sup>|yes|
|KT1V9Rsc4ES3eeQTr4gEfJmNhVbeHrAZmMgC|uusdtzbtcV3|yes|yes<sup>2</sup>|yes|
|KT1DHndgk8ah1MLfciDnCV2zPJrVbnnAH9fd|uusdtezV3|yes|yes<sup>2</sup>|yes|
|KT1F1JMgh6SfqBCK6T6o7ggRTdeTLw91KKks|uusdsirsV3|yes*|yes<sup>2</sup>|yes|
|KT1TcCSR24TmDvwTfHkyWbwMB111gtNYxEcA|uusdtezV3_0|yes|yes<sup>2</sup>|yes|
|KT1H2514Wb6G38fmgU3vpAwkWEpFC9sq7HPH|uusdsirsV3_0|yes|yes<sup>2</sup>|yes|
|KT1B2GSe47rcMCZTRk294havTpyJ36JbgdeB|udefiuusdV2|yes*|yes<sup>1</sup>|no|
|KT1LQcsXGpmLXnwrfftuQdCLNvLRLUAuNPCV|udefitezV2|yes*|yes<sup>1</sup>|no|
|KT1E45AvpSr7Basw2bee3g8ri2LK2C2SV2XG|udefisirsV2|yes*|yes<sup>1</sup>|no|
|KT1VjQoL5QvyZtm9m1voQKNTNcQLi5QiGsRZ|ubtctezV2<sup>l</sup>|yes|yes<sup>1</sup>|no|
|KT1NFWUqr9xNvVsz2LXCPef1eRcexJz5Q2MH|ubtcsirsV2<sup>l</sup>|yes|yes<sup>1</sup>|no|
|KT1CP1C8afHqdNfBsSE3ggQhzM2iMHd4cRyt|ubtctezV3|yes|yes<sup>2</sup>|yes|
|KT1G6RzVX25YnoU55Xb7Vve3zvuZKmouf24a|ubtcsirsV3|yes|yes<sup>2</sup>|yes|
|KT1XH5rKSd6Ae3DAMYi26gEZP1gxAoQRYRfS|ubtctzbtcV3|yes|yes<sup>2</sup>|yes|
|KT1SEjPmaeVPMu4Ep94ggF3tLqzFM83T3pBd|ubtcsirsV3_0**|yes|yes<sup>2</sup>|yes|
|KT18x66448Gt3kYYkfvx4Cg2dP9cRPfjQwVv|ubtctzbtcV3_0**|yes|yes<sup>2</sup>|yes|
|KT1AnDFRcdB652Jy5JFtmu7SampSPAzDkK7g|uxtzusdtV3|yes|yes<sup>2</sup>|yes|
|KT1Mf9Nr1KyGC6gUz9pGQnngzWbbZ6thShvc|uxtztezV3|yes|yes<sup>2</sup>|yes|
|KT1ByNrcyDxYLmamuJbeFJukYkLJaZ1W86Yr|uxtzsirsV3|yes|yes<sup>2</sup>|yes|
|KT1VhU47n633rqJeAZESfbejnxeJmpXVx3AA|uxauusdtV3|yes*|yes<sup>2</sup>|yes|

Savings Pools:

| contract | what | set admin | 
| -------- | ---- | --------- |
|KT18bG4ctcB6rh7gPEPjNsWF8XkQXL2Y1pJe|uusdsavingsV3|yes|
|KT1WT8hZsixALTmxcM3SDzCyh4UF8hYXVaUb|ubtcsavingsV3|yes|
|KT1KShHvxW69YukaGetdgYRTw31d9BX8ijfF|uxtzsavingsV3<sup>l<sup>|yes|
|KT1TMfRfmJ5mkJEXZGRCsqLHn2rgnV1SdUzb|uusdsavingsV2<sup>l<sup>|yes***|
|KT1KNbtEBKumoZoyp5uq6A4v3ETN7boJ9ArF|ubtcsavingsv2<sup>l<sup>|yes**|
|KT1Kvg5eJVuYfTC1bU1bwWyn4e1PRGKAf6sy|udefisavings<sup>l<sup>|yes***|
    
Other contracts:
    
| contract | what | set admin |
| -------- | ---- | --------- |
|KT1Ge5usHwAAH12PDxwP8FFYMdbMbXSRXSz4|stakemanager|yes|
|KT1KXvsh7vnPUkBj1oG1E3LUoFnKHsf7Wixo****|rewardcollectorv2 | yes |
|KT1USKq4gHFVs7WJSVsqKn8j8P4tmqZcgSbd|uusdusdtfarm | yes |
|KT1QtZLMqTKh3Q55Yhu8SZHApKnJ2Bz9bBWU|uxauuusdfarm|yes|
|KT1At1kk3y6a6UGHjZnAg6xeh3RgFbXNEJ4V|uusdubtcfarm|yes|
|KT1JFsKh3Wcnd4tKzF6EwugwTVGj3XfGPfeZ|uusdusdtzfarm<sup>l<sup>|yes*|
|KT1Ug9wWbRuUs1XXRuK11o6syWdTFZQsmvw3|uusdwusdcfarm<sup>l<sup>|yes*|
|KT1W78rDHfwp3CKev7u7dWRJTBqLdwYVcPg9|uusdudefifarm<sup>l<sup>|yes*|
|KT18x3gGRMKyhzcBnKYSRrfqjnzu4fPE1Lzy|uusdquipufarm<sup>l<sup>|yes|
|KT1Goz5Dsi8Hf7fqjx5nSEcjp6osD9ufECB2|uusdyoufarm<sup>l<sup>|yes|
|KT1RLGwCgeq2ab92yznQnJinpqy9kG13dFh2|uusdxtzfarm<sup>l<sup>|yes|
|KT1M9T11hrSuDXWDqjTUC2iNPCyypA3BsMrm|youxtzfarm<sup>l<sup>|yes|
|KT1HbzGokeEZ4hu1KRAAw2fyB61RCpBhQXKA|uxtzxtzfarm<sup>l<sup>|yes|
|KT1HaWDWv7XPsZ54JbDquXV6YgyazQr9Jkp3|uusdkusdfarm<sup>l<sup>|yes|
|KT1KGfEyxBeCU873RfuwrU1gy8sjC1s82WZV|ubtcuusdfarm<sup>l<sup>|yes*|
|KT1CpXvNd293VvHkY7M9krjBvwEFuvura65Q|uusdusdcefarm<sup>l<sup>|yes|


*remove tz15Q8f or old multisig from admins. Set multisig as admin in the uxau contract.
**change liquidation_payout_ratio (ubtc issue)
***add new DAO as admin
****change fund receiver to new collector contract
<sup>l</sup> is a legacy engine/contract
<sup>1</sup> is currently sending it's rewards to the unified staking pool
<sup>2</sup> is currently sending it's rewards to the reward collector KT1...Wixo

These multisig operations will be executed once the YIP is accepted, but it's lambda is not yet executed. Once the multisig operations are done, the above YIP will be executed. 

    
## Cleanup Phase

In the past, three different contracts collected, swapped and forwarded the rewards of engines and flat curve contracts. The cleanup phase will be used to deploy a new reward recipient 

#### Deploy new reward collector contract
    
- deploy new reward collector to mainnet
- create necessary exchange lambdas on this contract   
    
#### YIP / Multisig Operations: Set reward recipient contract as reward recipient on all flat curves

In order to set this new reward recipient as the only reward recipient, another YIP will be necessary for all single-admin contracts and additional multisig operations will be necessary. This can be done using the new DAO contract and the new bailout pool stakes.

- set reward recipient from old staking pool / reward collectors to the new reward collector on all single-admin contracts via YIP using the new DAO
- set reward recipient from old staking pool / reward collectors to the new reward collector on all multi-admin contracts via youves keyholder multisig


#### Move remaining reward collector funds
    
Rewards still sitting on the older reward collecting contracts, must then be moved to the newest reward colector, where they can be swapped. 
    
- move reward funds from old reward collector KT...wixo to the newest reward collector - youves multsig
- move funds from the oldest reward collector KT...USxb to the newest
  - by creating a designated exchange lambda for the unified staking contract
  - by executing that lambda with the multisig
- move reward funds from the unified staking contract to the new reward collector
  - by creating a designated exchange lambda for the unified staking contract
  - by executing that lambda with the multisig


#### Closing remarks

This migration will take a couple of weeks to be concluded. We carefully thought about the necessary steps which have to be done and in which order they need to be concluded to not increase any risks or to not open attack vectors. We are confident that this migration can be concluded as described. 

This might mitigate upcoming concerns coming from the fact that stakes are esentially moved from one DAO contract to another, making the DAO contracts at least theoretically vulnerable to malicious actors or exposed to the risk not being able to meet the quorum:

- a governance vote takes time: before voting, after voing and before execution. It's hard to sneak in a governance proposal without being noticed
- substantial quorum and supermajority must be reached in order to be able to win a vote
- youves keyholders can veto a malicious governance proposal, even if somebody managed to propose a malicious proposal
- youves keyholders are admin on multi-admin contracts too
- quorum does adjust within upper and lower cap, if it is not met during a vote








>#### Questions (internal)
>    
>- Should the new DAO replace the old DAO on multi-admin contracts or should we have them in parallel for a moment? - no ofc not
>
>- Can you confirm that the DAO votes should come first and only after both succeeded, the multisig admin settings will come - yes
>    
>- Change the reward recipients on the flat curves at the same time or not - pro and contra - yes
    
>- what risk is involved in having the old DAO still as admin on engines, while already moving stakers to the new DAO? Ideally we should only do the multisigs AFTER the YIPs succeeded