## yyXTZ recovery operation - request for signatures ### Summary We'd like to conduct a recovery operation in order to recover assets trapped in a Quipuswaop contract, due to a buggy LP token contract. The solution is a controlled drainage of the youves uXTZ/XTZ dex and a following distribution of assets to all liquidity providers of this pool. This requires a special contract (the flashswap contract) to be administrator on the main synthetic asset contract. We request the youves keyholders to sign a lambda which sets this flashswap contract as an administrator. ## Detailed description of the recovery operation As outlined in our postmortem https://docs.youves.com/postmortems/postmortem_incident_8 there are currently more than 200k yyXTZ tokens, liquidity tokens of the youves uXTZ/XTZ dex (`KT1BFXgczFte2zftCTg7tL6Qk2capsFg6UFS`) trapped on a Quipuswap contract (`KT1VVLLnLLZEwewB6g8fj7BMDsnsaU72Vatx`). Those LP tokens can never be withdrawn (see postmortem). The Quipuswap contract currently holds 396.34 uXTZ and 201'877 yyXTZ, representing 58'835.68 XTZ and 144'207.37 uXTZ on the youves uXTZ/XTZ dex. youves core contributors came up with a solution which allows to recover nearly all of the trapped funds, but it involves a uncommon operation, which is essentially draining the youves uXTZ/XTZ dex KT1BFXgczFte2zftCTg7tL6Qk2capsFg6UFS. After draining, the funds will be distributed pro rata between the yyXTZ liquidity token holders, including those who deposited their yyXTZ into the Quipuswap contract. To contduct this controlled drainage, a special smart contract was developed, which we call the "flashswap" contract. This contract was deployed alongside with an identical pool, inluding the buggy LP token contract, on ghostnet and was sucessfully tested under realistic conditions. Flashswap contract, on ghostnet: `KT1Sf3qxVErauSyk4oegpMjvf85ddx9Uo8eB` ([BCD](https://better-call.dev/ghostnet/KT1Sf3qxVErauSyk4oegpMjvf85ddx9Uo8eB/operations)) uXTZ/XTZ pool contract, on ghostnet: `KT1Vc1jG85EHH9SLqWCpH2DdtTtnCnCHor55` ([BCD](https://better-call.dev/ghostnet/KT1Vc1jG85EHH9SLqWCpH2DdtTtnCnCHor55/operations)) Buggy LP token contract, on ghostnet: `KT1WKYXzTjj64nU6vF8Vxht9eZFC1bga8ZKq` ([BCD](https://better-call.dev/ghostnet/KT1WKYXzTjj64nU6vF8Vxht9eZFC1bga8ZKq/operations)) This is how it works: ### Step 1: Preparation (Keyholder signature): The flashswap contract needs to be made administrator of the synthetic asset token contract and will have the right to mint unlimited uXTZ. On Mainnet that is `KT1XRPEPXbZK25r3Htzp2o1x7xdMMmfocKNW` with tokenID 3. Keyholder signatures or DAO acceptance are required to set the flashswap contract admin on the synthetic asset token contract. We decided to request signatures from the keyholders in this case, because a DAO vote will take 7 days to conclude in which malicious actors could try to find attac vectors. To our best knowledge there are none and the contract has been tested multiple times, but we would rather have that advantage. Additionally, we already pointed out in the post mortem, that we will come up with a solution that includes controlled drainage of the pool: https://docs.youves.com/postmortems/postmortem_incident_8#resolution. ### Step 2: Execution (2/3 Multisig executes flashswap contract) Once the flashswap contract is set as admin of the synthetic asset contract, the designated admin of the flashswap contract, a 2/3 multisig wallet controlled by Alessandro, Florin and Markus (`KT1KAr9hnFEEFXmJ1EUS4ZYMy9G8eK7bHbQM`) is allowed to call the entrypoint `flash_swap` of the flashswap contract. Calling it with an amount of synthetic assets to be minted, a series of operations is triggered of which the relevant ones are: 0. flash_swap: is called with parameter `99999999000000000000` which will mint 99'999'999 uXTZ 1. mint: The amount of uXTZ which was defined as parameter during the call of flash_swap will be minted from the synthetic asset contract, with the flashswap contract as owner 2. mint: The identical amount of uXTZ which the dex pool had before flash_swap was triggered will be minted to the receiver address, which was set to the same 2/3 multisig address controlled by Alessandro, Florin and Markus (`KT1KAr9hnFEEFXmJ1EUS4ZYMy9G8eK7bHbQM`) upon deployment of the flashswap contract (more info about this multisig below) 3. tokenToCash: The minted amount of uXTZ is swapped against XTZ, the XTZ is sent to the same 2/3 multisig receiver address (`KT1KAr9hnFEEFXmJ1EUS4ZYMy9G8eK7bHbQM`) 4. burn: The complete remaining uXTZ balance of the dex pool is burned, this includes the additionally minted/swapped and the previously present balance This all happens in one operation, so either all steps suceed or all steps fail. There is no way the operation group could stop inbetween and leave the contracts in unwanted states. As a result, nearly all of the XTZ and all of the uXTZ will be on the 2/3 multisig wallet and the pool will only be left with 0.000001 XTZ. To wrap it up, here's a comparison of before and after the execution of the contract: **Before:** dex pool has 60250.093562 XTZ and 159,643.297411272391 uXTZ receiver has 0 XTZ and 0 uXTZ **After:** dex pool has 0.000001 XTZ and 0 uXTZ receiver has 60250.093561 XTZ and 159,643.297411272391 The global balance of uXTZ before and after the execution will stay exactly the same as the same amount will be burned as was minted. ### Step 3: Distribution (2/3 Multisig distributes recovered funds) Once the uXTZ and XTZ have been safely received by the 2/3 multisig wallet controlled by Ale, Florin and Markus, we will calculate the exact amounts to redistribute, based on the yyXTZ holdings at the block level when the operation was executed. Every holder (or depositor of yyXTZ to quipu) will receive his/her pro rata share, sent manually from the multisig wallet. The Youves Operations Multisig wallet is `KT1KAr9hnFEEFXmJ1EUS4ZYMy9G8eK7bHbQM` and was set up using tzsafe from marigold, which we already use for operational purposes like sending funds to processors etc. ## Final thoughts, adressing possible concerns We are aware of the uncommon nature of this operation. But we think if this is the only possible way to recover around $ 135k value of assets trapped, then we sould do it. We are also aware that this might raise concerns in some users, seeing that we, together with the keyholders, are able to mint any arbitrary amount of synthetic assets. We will ensure that the community is able to understand this move. Additionally, we could go a step further after we concluded this operation and propose the community to remove the youves keyholder multisig from the engines and the synthetic asset contract and give the full control to the DAO only. Let us know if there are any questions or concerns we should address. If there are non, we ask you to sign the lambda which will set the flashswap contract as an admin on the main synthetic asset contract. Thank you for our engagement, Markus, Alessandro, Florin