Outline current state of the collateral simulations

[valiafetisov]

Goal

List of supported and unsupported collaterals, list of potential fixes

Context

Since we're working on the collateral auctions simulations for quite some time already and faced different kinds of problems, we need to summarise somewhere its state and come up with a list of solutions to move forward and prioritise them. Therefore, let's summarise it here or even create/modify test script that will do it for us.

Assets

Issues where simulations were previously developed and improved:

• Original issue with the approach to modify VAT balance and call drop Create a simulation for vault liquidation #464
• Support for fetching of CRVV1ETHSTETH-* vaults Add support for CRVV1ETHSTETH collateral vaults. #484
• Directly modify wallet balance instead of VAT balance Change ERC20 balance for collateral auction simulation #495
• Skip YFI-A testing Catch Vat-ceiling-exceeded #500

Previous state: #479 (comment)

Tasks

• Outline current state of the simulations (via a script so it can be run periodically or by hand)
  • Post a single comment with a table collateral type - state - reason
• Outline solutions / link existing issues that were created to overcome known limitations
• Create new issues, prioritise work
• Keep track of the progress in this issue until all collaterals are supported

[valiafetisov]

• ✅ supported – we're able to create a vault and liquidate it
• ⚠️ not testable – we're able to create a vault and liquidate it, but currently it doesn't work due to some conditions (offboarded collateral types, other reasons why no more vaults can be opened)
• ❌ not supported – our code doesn't support creation or liquidation of those vaults

Collateral type	State	Reason
ETH-A	✅ supported
ETH-A	✅ supported
ETH-B	✅ supported
ETH-C	✅ supported
LINK-A	✅ supported
MANA-A	✅ supported
RENBTC-A	✅ supported
WBTC-A	✅ supported
WBTC-B	✅ supported
WBTC-C	✅ supported
MATIC-A	✅ supported
WSTETH-A	✅ supported
UNIV2USDCETH-A	✅ supported
AAVE-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
BAL-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
BAT-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
COMP-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
GUSD-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
KNC-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
LRC-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
PAXUSD-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
TUSD-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
UNI-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
USDC-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
USDC-B	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
USDT-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
ZRX-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
UNIV2DAIETH-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
UNIV2ETHUSDT-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
UNIV2WBTCDAI-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
UNIV2WBTCETH-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
UNIV2LINKETH-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
UNIV2UNIETH-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
UNIV2AAVEETH-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
UNIV2DAIUSDT-A	⚠️ not testable	MCD_VAT.ilks().line == 0 Max debt set to zero
YFI-A	⚠️ not testable	Vat/ceiling-exceeded Error during vault opening #500
CRVV1ETHSTETH-A	❌ not supported	Lacking programmatic mean to open this type of vault. Opening is done via different mechanism based on cropper
UNIV2DAIUSDC-A	❌ not supported	Dog/liquidation-limit-hit Liquidation limit too high
WSTETH-B	❌ not supported	Dog/not-unsafe: Successful vault creation, but stability fees did not change after time warp
RETH-*	❌ not supported	Join contract does not have enough collateral. Will be addressed in #495

[valiafetisov]

Solutions

• MCD_VAT.ilks().line == 0
  • a) set MCD_VAT.line via MCD_VAT.file method (impersonating proper account) Enable calling auth-protected methods for testing #505
• Vat/ceiling-exceeded
  • a) same as above (ie call MCD_VAT.file) Enable calling auth-protected methods for testing #505
  • b) find and liquidate existing vault
• Dog/liquidation-limit-hit
  • a) set MCD_DOG.hole via MCD_DOG.file method (impersonating proper account) Enable calling auth-protected methods for testing #505
• Dog/not-unsafe
  • a) call MCD_JUG.file (impersonating proper account) Enable calling auth-protected methods for testing #505
• CRVV1ETHSTETH-A
  • a) add support for proxy-type vaults Feat: add vault opening simulation for CRVV1ETHSTETH #503
  • b) find and liquidate existing vault (doesn't let us create new vaults for new proxy-type collaterals)
• RETH-* as well as other new collaterals hopefully will be supported by the Change ERC20 balance for collateral auction simulation #495
• REN-BTC, GUSD
  • a) add support for the proxy-type tokens Feat: add capability to overwrite balances of the proxy-based tokens #504
  • b) remain with the fallback option of overwriting VAT balance instead of wallet balance

[LukSteib]

MCD_VAT.ilks().line == 0 as well as Vat/ceiling-exceeded I assume can be fixed by setting MCD_VAT.line via calling file method (impersonating proper account)

One remark here: As this relates to all of the collateral types that have been offboarded (also the reason why MCD_VAT.ilks().line == 0) let's be mindful with our resources and not trying to make these work for now.

[KirillDogadin-std]

Dog/not-unsafe

same: impersonate, call file on jug.sol contract

propose a solution here?

See #503

[KirillDogadin-std]

Created #503, #504, #505 as sub-issues

[valiafetisov]

Thanks! Please link them to the appropriate points in #501 (comment)

From my perspective, CRVV1ETHSTETH-A support is quite important, as it will allow us to do long-outstanding #376. But maybe find and liquidate existing vault is more suitable approach here? Can you please compare implementation complexity of the two and maybe even propose a third one?

[KirillDogadin-std]

Sorry, i don't understand the things that you're asking to compare.

The first one i assume is #503 as it is. The second is "find&liquidate existing vault". I either don't see the common line/ground there, or i did not get one/both of the compared items correctly

• Edited the comment you've linked

[valiafetisov]

Sorry, i don't understand the things that you're asking to compare

The comment with solutions specifies two options to support CRVV1ETHSTETH-A, a) and b). #503 covers option b), not both of them. There are 3 questions to you:

1. Can you please outline option a)?
2. Can you please propose another options?
3. Can you please compare available options (at least a) with b)) in terms of complexity/effort?

Edited the comment you've linked

Please edit the links so they correspond to specific solutions, not problems, since there can be many solutions per problem

[KirillDogadin-std]

• The comment you've linked actually claimed (i edited) that the solution for support of CRVV1ETHSTETH-A is to support proxy-type tokens. Which is not the solution since this token is not using proxy. CRVV1ETHSTETH-A vault does use the proxy on the other hand.
• RENBTC is a proxy type token, hence there's currently "1 stated solution" which is outlined in the linked issue

Option (a) is outlined for CRVV1ETHSTETH-A in the linked issue. Option (b) would be heavily dependant on the mechanism that we should have by the end of the current global scope (i.e. ideally having the api at hand that we can use to query for vaults of specific type). For now it seems like the solution would be to:

1. iterate over every vault that CDP-MANAGER is aware of, use ilks to get the vault type
2. Collect the vaults of the required type, figure out the vault address (since it's proxied address we need additional steps):
   • query the owner of the vault in CDP-MANAGER (it must redirect to the registry)
   • get the owner of the vault in the CDP-REGISTRY (it must be a ds-proxy constract)
   • filter the events in the CROPPER contract: NewProxy is the name, the vault owner (ds-proxy) address is the parameter to filter by.
   • impersonate the ds-proxy's owner account, draw debt from the vault via calling frob function in the CROPPER contract via this proxy
     • if needed, overwrite ds-proxy's owner balance via the existing functionality so it has more CRVV1ETHSTETH-A token
   • pass time (risk factor: if at some point the stability fees are 0, we have to be able to file the new values.)
   • liquidate.

the listed option seems like an easier thing to implement at first glance. The deal-breaker here is the fact that there's no need to deploy a ds-proxy contract into the fork.

[KirillDogadin-std]

adding the support for CRVV1ETHSTETH-A in #510

• update table when merged

[KirillDogadin-std]

Summary of currently known proxies that are used with the supported collaterals one way or another:

1. REN-BTC

a proxy-based token. This means that the logic of this token is specified in another contract, while the information is stored in the token(proxy) contract.

wallet --function_call--> REN-BTC --delegatecall--> REN-BTC-LOGIC
                      [info storage]               [logic storage]

2. CRVV1ETHSTETH-A

a usual token. But the vault is proxied.

The vault can be created and instantly drawn from if one uses DSS-PROXY-ACTIONS type of contract (e.g. 0xa2f69F8B9B341CFE9BfBb3aaB5fe116C89C95bAF). One has to use DS-PROXY when making a call to it for security/safety reasons.
Under the hood the following happens:

• The vault is "reserved" in the CDP-MANAGER by CDP-REGISTRY.
• CDP-REGISTRY keeps track of who is the actual owner of the vault. (the actual owner will be DS-PROXY)
• then the call to the CROPPER is made - this is the variation of join contract that holds the funds that are deposited into vat.
  • the cropper creates the proxy of the vault and uses its address as the holder of the funds.
  • the actual vault's address that has been created by the CDP-MANAGER is not used.

wallet -call-> DS-PROXY -call-> DSS-PROXY-ACTIIONS-CROPPER -> 1. CDP-REGISTRY -> CDP-MANAGER
                                                           -> 2. CROPPER-PROXY -delegatecall-> CROPPER-IMPLEMENTATION

[KirillDogadin-std]

Additionally, GUSD (gemini) token now is hidden behind the proxy. This means that we have two cases that require to fallback to increasing vat balance currently (instead of increasing wallet balnce) during the simulations:

1. REN-BTC
2. GUSD

Updated #501 (comment)

[KirillDogadin-std]

Removing the fallback of increasing vat-balance instead of wallet for proxy-based tokens seems trickier than expected. There seems to be no consistent layout of where the data is stored. For instance, the G-USD token has a separate storage contract that is referenced by the logic one. But sadly the same layout does not appear to be present for ren-btc. Which essentially means that it's not exactly clear what's the uniform way of overwriting storage of the proxy-contract.

As of "what if it just works" - running balance slot discovery on the GUSD and RENBTC did not work out for both cases: overwriting the logic contract and the token contract/