TL-DR: Add sDAI and LUSD as collateral to mint GHO via Dullahan
Context:
Dullahan was released in August with the 7 largest collaterals at that point in time. While the ranking hasn’t really moved, we are requesting to add both sDAI and LUSD.
Rationale:
LUSD: we support decentralization and believe that LUSD needs more integrations in order to spread. Adding LUSD to Dullahan creates new avenues for users to leverage it.
sDAI: Maker’s savings rates is the leading wrapper for Real World Assets with 1600M$ of TVL. Enabling it will allow people to leverage their access to the DSR. This asset is enabled in the wake of a new community product being built on top of Dullahan.
It makes sense… but now that you bring this up, I wonder if it would have made sense to vote on each collateral at the time of deployment?
For example, why don’t we have LINK and/or cbETH as well as accepted collateral? They are both more used currently as collateral than DAI, USDT and LUSD.
Also on the topic of adding collateral going forward, we should try to have new tokens added as soon as they get added on AAVE. I assume that if they were available from day 1, we could try to capture a portion of the new borrowers.
For the initial list of collateral allowed, we simply took the list of assets that were allowed as collateral on Aave V3, had a big TVL on the supply side, so it’s could be easier to attract. We decided not to list all assets to make sure the system was already working with the 1st basket of collaterals before adding some more.
As for adding new ones after they get listed on Aave V3, we could design a process for our DAO to allow new assets in an optimistic way, if a list of pre-requisites are filled by the new collateral (I’m not sure of all the required pre-requisites, I’ll let other contributor jump on the matter, but ig the basics should be “is allowed as collateral for GHO”, “Supply TVL is larger than a given $ value”, etc …)
Would it not be easier to integrate all tokens accepted as collateral on AAVE to mint GHO immediately on Dullahan? I don’t think the current approach of adding tokens through a vote (or applying a minimum TVL threshold) is reducing any risk for Dullahan. In case of a flash crash and slow liquidations, the losses would be suffered by AAVE (via the safety module).
As suggested on discord, it might be more effective to transform this proposal into a mass integration of all tokens accepted on AAVE (current and future) instead of just sDAI/LUSD.
I support adding sDAI & LUSD to Dullahan, both assets are relevant to be implemented.
However, I’m not sure this type of proposal should be categorized as PIP, while PIR (Paladin Integration Request) might be more suited for whitelistings.
If the goal is to define specific parameters for each asset whitelisting, a lower vote duration (3 days for PIR) might help enable the collateral on Dullahan quickly after the implementation on Aave. The quorum is also lower (10%).
As assets listings are frequent on Aave, requiring the higher vote duration (7 days) & quorum (20%) with PIP will increase the implementation delay.
These two points make sense & tbh I don’t have a clear opinion on if we should accept all assets or add an additional safety filter with whitelistings, but I can share a few thoughts:
One thing to consider would be the dev time to implement an asset (if too long, might be worth filtering relevant assets)
As mentioned above, whitelisting assets can be added in PIR, reducing the governance requirements/delays
While the SM is expected to be used in case of shortfall event on Aave, this has to be approved by Aave holders, which can decide to use the treasury instead (happened with CRV incident)
Tbh checking basics like GHO as collateral, min TVL value or even double check on the risk parameters for assets approved can’t hurt as an additional safety for Dullahan users
yes, but whether the shortfall is covered by the SM or the treasury is not something that will (or will not impact) Dullahan users specifically. The risk exposure for GHO borrowers via Dullahan is exactly the same as if you borrow directly via the AAVE front end.
I don’t think that whitelisting collaterals reduces the risk for Dullahan. For example, if AAVE’s governance goes crazy and decides to add a shitty collateral, would Dullahan users not be exposed in case of bad debt, even if the that collateral is not whitelisted on Dullahan? Are losses not mutualised between all GHO borrowers?
It’s a bit more complicate if we blindly list all the collaterals, because there is no way for us to close down / push for closure pods currently opened (but Aave can with their monetary policy or by modifying parameters). I think instead we should have an optimistic setup where we can veto new collaterals. What do you think?
I am in favor of adding sDAI & LUSD in Dullahan as both are well known and can be considered as “safe assets”.
Definitely in for an optimistic setup that allows Paladin governance to veto some assets. This would be more efficient for Paladin governance while still protecting Dullahan users.
Ofc, I meant it’s not done instantly as it can be discussed & has to be voted on Aave before, so it can take time.
But yes, if a shortfall event happens it would impact either the Aave treasury or the SM, but should not impact the users unless if the issue is bigger than the current cover available.
I’m wondering what technical ressources are needed to add each assets implemented on Aave to Dullahan though as it can be an important factor, any estimation @Kogaroshi ?
If closing pods requires a proposal on the Aave governance, it would still be required even with an optimistic whitelisting to add assets right ?
I don’t really get it… Can you think of an example of a situation where we would need to push for the closure of a pod?
I guess if the pod is already open, it means that the collateral had been considered at some point in time safe enough for AAVE governance to approve it. If we then wanted to force a user to close the pod, it would be because the situation around that collateral has changed drastically (for example CRV)? But in that case, wouldn’t AAVE push parameters changes through its governance to do just that? The question is, are there specific scenarios where the desired actions would be different for borrowers via AAVE and borrowers via Dullahan?
