Admin access control
DeFi Saver is a management app for decentralized finance positions with a varying level of admin controllable elements depending on the part of the app used.
We want to highlight different layers of smart contracts that should be distinguished.
A Smart Wallet, as referred to in the DeFi Saver app, is nothing else than the standard dsproxy, as used and popularized by MakerDAO and also used by prominent projects such as Balancer and Reflexer.
Each user has their own DSProxy Contract through which they interact with the DFS contracts. Most contracts in the DFS system are logic/target contracts that don't hold and state or funds and are called through the users DSProxy. In order to execute actions for the user (strategy system)
auth permission is given to the ProxyAuth contract which is immutable.These are the smart contracts used by our recipe architecture and utilized by users when using the DeFi Saver interface (application).
While these contracts are, for the most part, immutable, that isn't a specifically relevant characteristic, as they can be replaced in the registry and consequently in the UI when updating is needed due to adding support for more protocol interactions, optimising gas usage, or other reasons.
This smart contract holds the addresses of live DFS contracts retrievable by hashed contract name. With only the multisig owner being able to add new contracts, change existing ones or revert to the old one. When adding a new contract to the registry, a time lock can be added, so every time a new change of that contract is requested, it's locked from executing until enough time has passed. Core contracts have the timelock time set to 7 days while other action contracts that are used in strategies have a set change time of 1 day.
In order to validate wrapper exchange addresses this is a contract where we keep track of them. This contract holds the addresses of wrapper contracts (found here) that can be added/removed from the contracts via the multisig owner. These wrapper contracts are used when swapping tokens via DFSSell action, which can only be done via pre-approved wrappers.
This contract is the starting point for executing recipes.
It's a contract that doesn't hold state, owned by the multisig, which can kill or withdraw leftover funds from it. The functions on it are to be called through users DSProxy, along with all the necessary calldata. During recipe execution, the Action addresses that the proxy will execute are found through DFSRegistry, a state-holding contract that returns an address via bytes32 id (hashed name of the action).
Current Automation smart contracts are not in any way connected with our new architecture smart contracts, but we included the information here for purposes of easy access.
Automation is a trustless, non-custodial service for management of collateralized debt positions.
The logic for executing user configured actions is contained within Automation smart contracts and user configurations are stored on chain.
Automation contracts are upgradeable, with any upgrades being locked behind a 24h timelock which can be activated by a 2/3 multisig (Admin) with actual upgrades initiable by a different 3/5 multisig (Owner).
For more information about the security of Automation, we recommend visiting our security audit report summary post here.
Last modified 1yr ago