Create a simulation for vault liquidation

[valiafetisov]

Goal

A developer is able to start a simulation which will create a vault and turn it into liquidatable state.

Context

In order to test the new collateral types, but also vault logic, we need to create a reusable simulation steps in order to test related functionality. For this, let's implement a creation of a new vault and make this logic universal across collaterals. Eg:

• Create a vault via createActiveVault(collateralType) test logic
  • get tokens of a specific collateral symbol (via overwriting a mapping?)
  • set allowance, collateral auth
  • open vault, deposit collateral
  • ? withdraw all available DAI
• Make vault liquidatable by:
  • ? drip, ie collectProtocolFees(collateralType)
  • or setting OSM price (I guess it's more difficult to make it universal?)

Note:

• This can be implemented as part of the Implement vault liquidation core logic #460 or after it, in order to test vault creation

Tasks

• Come of with the final proposal on how to make it universal across collateral types
• Implement simulation

[KirillDogadin-std]

More specifically:

get tokens of a specific collateral symbol (via overwriting a mapping?)

• Option A: via harhdat_setStorageAt call

should work universally for all onboarder collaterals:

1. fetch the address of the VAT via getContractAddressByName
2. hre.call('harhdat_setStorageAt', [address, slotAddress, newBalance]) and overwrite the mapping that lists the amount of the collateral deposited in VAT for the specified wallet. - you can spot that there's slot` involved. This has to be hardcoded and maintained: if the vat contract gets updated the slot address might change.

• do all collateral tokens have the same slot address? irrelevant after the edit

• Option B (avoided): Use dai balance overwrite and try to swap this into the token we need:

  • limited to the amount of the tokens we can get into the test-wallet: there might be not enough open trade offers.

• @valiafetisov is this okey if we open the test-vaults with non-customizable amount of collateral in it? I would say it's not that bad but still hinders the testing potential.

• come up with the proposal on how to implement this option b if the approach is acceptable irrelevent after the answer to previous point

set allowance, collateral auth

• since collateral is generated in the owner's VAT:
  • extraction does not require permissions
  • joining to the vault contract needs the permission to access the funds of the wallet (given allowance)
  • the auth would apparently not be required still for the vault that is opened since it's managed by the cdp.

This functionality seems to already exist, so no additional steps seems to be required.

open vault, deposit collateral

• opening via developing a function that calls the the cdp manager contract with function open and calling frob to deposit collateral
  • add a function that opens the vault (calls open)
  • add the function that edits the vault contents (calls frob)
  • add the function that gives the vault permission to operate with the owner's VAT balances ( call hope with the vault's addr as the argument)
  • add the function that deposits collateral to the specified owner's VAT (calls join)

withdraw all available DAI

• join the collateral to the vault's contract ( vault's VAT has to have the collateral )

• seems to be possible via frob as well and (in the same call?) above:

  • in the same call? see the requirements here https://github.com/makerdao/dss/blob/fa4f6630afb0624d04a003e920b0d71a00331d98/src/vat.sol#L161-L173 @KirillDogadin-std
    • Answer: yes, possible in the same call

• use the existing vault.ts functionality to fetch the info about collateral from vat

• reimplement the logic from the above linked requirements to create a function that computes the maximum allowed debt:

  • accounts for information that has been introduced by vault liquidation logic (liquidation ratio < collateralization ratio)
  • accounts for the previously unaddressed parameter called line (debt ceiling) - has to be fetched from the chain via a function call for the specified type of collateral.

? drip, ie collectProtocolFees(collateralType)

if we withdraw all possible dai, then i assume this is the correct approach BUT

• there's a timeout so that the fees can't be collected every second. we might have to secure this funcitonality by calling warpTime on the testnet.

or setting OSM price (I guess it's more difficult to make it universal?)

yes, it is. let's avoid it as hard as possible 😓

[valiafetisov]

hre.call('harhdat_setStorageAt', [address, slotAddress, newBalance])

Would hardhat_impersonateAccount help? It is useful to call methods that require authorization.

Otherwise, I am not sure if you actually need to get tokens first. You might instead modify collateral balance in the VAT directly or write a script that opens a vault, then modifies its collateral size.

Use dai balance overwrite and try to swap this into the token we need:

Not every token is swappable on Uniswap, as you see, we already have several groups of collaterals that require different exchange callees and it's most likely that this script is helpful when there is no callee yet. So, this option is the least favourable.

non-customizable amount of collateral in it

Not sure what you mean. Of course it will be beneficial to set collateral + debt amounts semi-random to be able to test different scenarios.

[KirillDogadin-std]

Would hardhat_impersonateAccount help? It is useful to call methods that require authorization

Since I don't see the function that just edits the balance of the address at token contract of weth, I cannot say that it helps since impersonation of the token contract does not result into ability to edit some wallet's balance. Correct me if I'm on the wrong line of thinking.

Otherwise, I am not sure if you actually need to get tokens first. You might instead modify collateral balance in the VAT directly or write a script that opens a vault, then modifies its collateral size.

True, but same with the adjustment of the vat balance. I will double check tomorrow but now I've seen no function that can be called to generate collateral out of thin air

Not every token is swappable on Uniswap

Let's avoid, true.

Not sure what you mean. Of course it will be beneficial to set collateral + debt amounts semi-random to be able to test different scenarios.

Some swaps were failing back in the day when we converted DAI to mkr. That was because on the block number there apparently were no open trades that would allow swapping into desired amount

[valiafetisov]

True, but same with the adjustment of the vat balance. I will double check tomorrow but now I've seen no function that can be called to generate collateral out of thin air

Not the same, as there is only one VAT contract, right? If there is a single place, overwriting a mapping would be much more reliable than doing it for different token contracts.

[KirillDogadin-std]

Not the same, as there is only one VAT contract, right? If there is a single place, overwriting a mapping would be much more reliable than doing it for different token contracts.

True, missed this point. Then let's roll with overwrite of this single value. Updated the proposal

[KirillDogadin-std]

relevant article https://github.com/makerdao/developerguides/blob/master/vault/cdp-manager-guide/cdp-manager-guide.md