DeFi Saver Automation security audit summary

In January 2021 we approached the Dedaub team to arrange a security audit for our Automation services, after we surpassed $500m in collateralized assets managed by the system.

We decided to audit the current system, even though we have a major update in the works and the current system has been running for well over a year (Automation was originally introduced in September 2019) without any security issues found. The contracts are now managing a staggering amount of assets and we wanted to have additional confirmation that everything is in order. We would like to add that even though no external security audits have been done before this, the code has been continuously internally audited by the team, as we were previously a security auditing team ourselves.

The Dedaub team performed an extensive audit, with four auditors devoting their full attention to the audit for a duration of more than two weeks.

We would like to extend our gratitude for the effort they put in and attention to detail they’ve shown, as this was exactly the level of commitment we were hoping to see once we start working with auditors.

For anyone interested, you can find the full audit report here.

Summary of audit findings

The scope of the audit included Automation for Maker, Compound and Aave. While there are a lot of similarities between the three protocols and the associated Automation code, they were all audited.

The audit report highlights that no funds are at risk of being lost and that the overall security of the system is robust.

The security model of the app is solid. - Dedaub

There were no critical issues found and none of the mentioned medium or low priority issues currently pose any risk to the functioning of the system or to its users and their funds. These listed issues will be addressed in an updated version of the automation system, as we strive to constantly improve security and follow the latest best practices.

Like the audit report mentioned, there is some admin level control over the system, which was an intentional trade off at this stage of Automation development, and is something we believe our users are already aware of. While we do not have any control or access to user funds, we are able to change some parameters, like the amount of gas tokens being used or the maximum gas price that can be charged for any transaction.

We also have the ability to upgrade the (Monitor) contract which is behind a 24h timelock and you can check and follow any pending or previous upgrades here.

As mentioned, this current level of control is an intentional trade off, as it allows for a tighter security model where we can iterate on anything needed more quickly and only allow a certain set of our bots to run Automation transactions. However, properly managing the balance between control and trustlessness of the system has always been of paramount importance. That’s why the system is set up in such a way that users provide managerial access to a smart contract, and not us in any way, and the contract is coded in such a way that the system can only do what the user has specified.

For context, the relation between a user, their position and Automation goes like this: a user’s EOA owns a proxy wallet (known as Smart Wallet or dsproxy) that holds the user’s position (e.g. a Maker Vault or position in Compound or Aave) and the authorizations that allow Automation to run are given for the proxy to “Monitor” contracts (each of currently supported protocols has its own Monitor) that then have a trusted set of entities (Automation bots maintained by the team) that can run the adjustments for users.

This means that the Monitor contract has access to either Boost or Repay any user’s position based on what the user configured and has no other control over the funds.

Another thing mentioned in the audit was the use of a multisig for admin and owner-controlled accounts. Besides smart contract security, we take operational security just as seriously and all the privileged accounts in the system are multisigs.

Continuing on that, two privileged roles that we have in the system are the owner and the admin. The owner is currently used for parameter changes and contract upgrades, while the admin account is one step above and a stronger multisig that has the ability to change the owner account in case it’s ever compromised.

The moment we start moving towards decentralization of Automation, these are things that will of course greatly change, with the points mentioned in the audit being additionally reinforced to allow other entities to run Automation bots.

Closing thoughts

Improving and ensuring DeFi Saver security is an ongoing effort and having formal external audits from reputable teams is just one of the options we will utilize to continue to improve.

In addition to audits we plan to set up an official bug bounty for any whitehat hackers in the community. While we currently already offer bounties (and have already rewarded them) for finding security issues, we don’t have anything formal set up yet, which is something we want to resolve very soon.

Moreover, all of our new smart contracts moving forward will be audited before being deployed into production, starting with our upcoming architectural upgrade that we can share is being audited by the Consensys Diligence team.

If you have any questions or security concerns you would like to check with us, you’re absolutely welcome to join us in the DeFi Saver Discord at any time.

As always, stay safe and talk soon.

Stay connected:
🌍: DeFiSaver.com
💬: Official Discord
📢: Official Twitter