Automated Strategies - Technical Overview

Quick recap

(Largely adapted from our EthDenver presentation)

• As you may remember, DeFi Saver started off as CDP Saver back in early 2019. We focused on automating Maker CDPs, providing liquidation protection and automated leveraging.
• As 2019 neared its end, Maker moved to a multi-collateral system. Limited liquidity meant that users couldn't migrate their CDPs whenever they wanted. We deployed another automation service which monitored liquidity, and migrated positions when available.
• Along the way, CDP Saver expanded to other protocols and became DeFi Saver. Through 2020, we expanded our automation options to include Compound and Aave.
• As DeFi Saver expanded the feature set, we were urged by users to automate other protocols as well, such as Liquity and Reflexer. Users also requested other automation strategies, such as stop-loss and take profit position closing. Developing a large, monolith system for each one of these wasn't feasible. We needed to streamline our process by:
  - Restructuring and generalizing our backend system. This would allow us to reuse common parts, and make adding new strategies a simpler task.
  - Making our contracts system modular. By having a contract system based on small and simple actions, we can create and update complex on-chain operations quicker, easier and cheaper.

Recipes & Strategies

If you've ever Boosted your CDP before, you know it has 3 basic steps:

Furthermore, larger Boosts can also be powered by flash loans, adding additional steps before and after. Most complex transactions, like loan protocol shifts, or creating leveraged positions, can be done by combining these same basic steps, too.

In order to make development of DeFi Saver's signature features quicker and easier, we developed a system of modular contracts (Actions), that can be easily combined into a single transaction (Recipe). This system is open-source and available for anyone to use via our JavaScript SDK.

We also launched the Recipe Creator as the system's proof of concept last year. It lowered the entry barrier for the famous DeFi Legos idea, and brought its power closer to users unfamiliar with Solidity. By dragging and dropping the actions in the Creator, a user can benefit from access to flash loans and create interactions between their wallet and multiple protocols.

This new smart contracts architecture was a mandatory change to our previous approach on the way to creating a more versatile automation system that could support a vast variety of automated Strategies.

An automated Strategy consists of a set of triggers, and a Recipe that gets executed when the trigger conditions are met. This is how our solution for a more generalized automation system looks like when broken down to basic elements.

Under the hood

If you've ever looked into Maker's contract system, you know each position is owned by the user's DsProxy (what we refer to as a Smart Wallet). The situation is similar for other protocols used in DeFi Saver (like Aave & Liquity). It's owned and solely managed by the user. It also provides an execution context, enabling execution of complex transactions.

DsProxy contracts are fairly straightforward. The essence lies in the execute method. It allows the wallet's owner (the end user) to execute an arbitrary transaction, eg. a recipe.

These smart wallets also integrate an authorization system, allowing the user to allow external contracts to call the execute method. DeFi Saver's automation system uses this mechanism to allow our bots to execute the user's desired recipes. In order to keep this safe and trustless, the permission is given to the ProxyAuth contract, which is immutable, can only be called by the StrategyExecutor and can only call RecipeExecutor.executeRecipeFromStrategy. RecipeExecutor then checks if trigger conditions are met, and executes the recipe.

When a recipe is executed as part of a strategy, some parameters need to be variable because they depend on external factors and execution-time state. For example, the boost amount that depends on the current CDP ratio, the optimal exchange order that is calculated off-chain, etc. However, allowing all parameters to be specified by bots would be an important security flaw. For example, it could allow our system to specify a different CDP ID when executing a Repay, effectively providing a way to extract funds. To avoid this, most arguments of a strategy are hardcoded as part of the user's subscription to a strategy, such as CDP ID, wallet addresses, selected assets, etc.

With gas prices as high as they are on Ethereum L1, we always do our best to optimize gas usage as much as possible. A nice little hack we came up with for the new automation system is to avoid storing the whole subscription data on-chain (which is the most expensive part) and to only store the hash of the data, while logging the whole data in an event as backup. This way we ensure that the data is available and easily fetchable by anyone, while also verifying the full data structure against the hash by the StrategyExecutor whenever bots execute any strategy.

Note: this is a summary of more extensive documentation, available here.

Overall, this modular system provides a framework to more easily expand the scope of automated strategies available to the end user, while keeping the system as safe and trustless as it's always been. We're slowly rolling out the system, starting with one set of strategies that will protect users' Maker CDPs from liquidation by automatically withdrawing from their savings account (Yearn, mStable and Rari Finance) when needed, and paying back their debt. You'll be able to check these out as soon as Monday, March 7th.

Moving forward, we will slowly add other, long-requested strategies. Eventually, we hope to allow more tech-savvy end-users to create their own automated strategies from scratch. If this sounds like something you'd like to be a part of, drop us a tweet or a message. As always, we'd love to hear your thoughts!