[DIRECT-AAVEV2-DAI] Direct Deposit Module Technical Assessment

General Information

Risk Summary

  • Risk analysis : MEDIUM.

Technical Information

  • Compiler versions :
    • Aave V2: v0.6.12+commit.27d51765
    • MIP50: v0.6.12+commit.27d51765
  • Upgradeable contract patterns :
    • Aave V2: Yes
    • MIP50: No

Contract Risk Summary

This is a medium risk contract. The dss-direct-deposit adapter has been built by Maker’s internal team and will be undergoing an audit before raising beyond a test debt ceiling. Most of the risk comes from Aave’s smart contracts. They use an upgradable pattern with Aave’s governance in charge of any future upgrades. Maker opens itself up to Aave governance attack by integrating this module. In particular Aave’s governance delay is 1 day vs Maker’s current 2 day delay. This will prevent us from being able to react to any governance attack before it gets executed.

Aave V2 has undergone 6 audits and the protocol is one of the most popular with billions locked in TVL for almost a year now. The risk of an undetected exploit being found at this stage seems small, but should not be completely discounted due to the complexity.

6 Likes

What could a rogue Aave executive do at worst?
edit: by executive I mean executive spell, I don’t know Aave terminology!

1 Like

Governance has full control over the implementation. They could steal all the collateral if they wanted.

3 Likes

Is there a way to mitigate this technically? Or do we need to find non-technical solutions to allow this to scale?

Technically, DAI being decentralised as it is, I don’t think there is any way to do it, that’s why hackers or protocol exploiters always use DAI as a bargaining chip.

Best solution to scale this is for Aave to have longer timelocks for dangerous operations such as contract implementation upgrades. It will give us time to react in the event of governance attack.

This is the same risk we accept with most other collaterals btw.