Destiner's Notes
Blog

Wallet Delegate

28 July 2019

Ethereum is a vast achievement in the ability to program value. In just a few years, Turing complete language tied to sound money allowed to start several interesting financial experiments.

As there is a lot of talking about user experience, it’s worth to remind that the best UX is no UX. What can be automated should be automated, and currently, a lot of interactions on the blockchain can be done automatically.

The biggest barrier seems to be infrastructure. Namely, an extensible and flexible set of permissionless smart contracts. In terms of setting access control to different features of contracts, most of the applications will have very similar requirements, namely roles, actions, and security measures.

Here, I outline the concept of Wallet Delegate (WD). In a few words, WD is an extensible smart contract wallet. It allows one person to deposit funds, another person to create a strategy to operate those funds, and the third person to execute those operations.

Note: this outline will mostly focus on use cases inside DeFi. WD, however, would fit anything that requires repetitive actions that can be formalized and would benefit from delegation and automatization.

Disclaimer: this outline doesn’t consider the legal side of operating WD. As a rule of thumb, managing other people’s money in a trusted setup usually requires some kind of accreditation. Luckily, it’s possible to decentralize such system in a way that the managing is done by smart contracts, and the impact of external actors will be limited to triggering certain functions.

Properties

Let’s start by defining what we want from such a system. Security is the priority here, so unless the user explicitly tells otherwise, no one can access their funds, including trustless smart contracts. In that sense, the initial features of our contract are similar to the WETH contract: user can deposit, withdraw, and learn his balance. All strategies are opt-in.

Next thing is variable access control. Namely, being able to set different rights to different operators at any level of granularity. Operator’s influence might range from being able to deposit the user’s ether into Compound to providing custom portfolio rebalancing at any amount and time.

A large strength of such a system comes from modularity. Being able to define custom strategies, connectors, and roles will help to unlock many possibilities that are simply impossible to achieve without some level of trust at the moment, even in the realm of Ethereum.

Finally, we want the system to remain permissionless. Not a single party has more power in the system than others.

As a bonus, we will achieve some level of auditability, as each action is written into the blockchain.

It might be beneficial to discuss what doesn’t seem to be necessary for the system. Namely, governance. The strategy here is to keep core contracts simple. In fact, the system will be informally governed off-chain (e.g. online discussions of different strategies and operators), while giving some insight on-chain (e.g. AUM or operational volume of a given strategy). The core contracts will be immutable. The strategy contract might support switching to another set of core contracts in case there will be an upgrade or bug fix.

Design

There are users and operators. Users transfer assets and choose strategies and operators. Operators execute those strategies under rules strictly defined by the smart contract logic. An operator can be a person or a smart contract, triggered manually or automatically.

Assets are held inside Fund contract. This contract serves as an entry point to the WD for the user. In some cases, Fund might be the only contract that a user interacts with.

Business logic is handled by Strategy contracts. These contracts define what would happen once certain actions are triggered. Actions are succinct, high-level definitions of operations that usually involve multiple connectors. An example of action is rebalance.

Strategy contracts talk to external contracts via Connector contracts. These connectors are simply high-level wrappers around other contracts. Strictly speaking, connectors aren’t required for the system to operate, although given that multiple strategies are likely to conduct similar operations with the same contracts, having them seems efficient.

Strategies

Here, I describe several strategies to start with. Most of these are already implemented or being discussed to be implemented in some form or another.

Portfolio rebalancing

A common scenario is to keep a portfolio of assets in predefined proportions. Another option is to let someone else set those proportions. Either way, it could be automated in a trustless manner.

This strategy will use connectors like 0x, Uniswap, Oasis. Assuming we will have a decent oracle, the smart contract will ensure that the values of the assets corresponding to the proportions defined by the user or portfolio operator.

Lending arbitrage

It’s in lenders best interest to pursue the best yields available on the market (considering the risk). Given that it’s possible to read supply rates for most of the protocols on-chain, one can create a strategy that would swing assets on user’s behalf, following the best offerings at the time.

A strategy like that would connect to protocols like Compound, dYdX, Fulcrum.

Long ETH

Just when the ether price starts to rise, a popular thing to do is to create a CDP on MakerDAO to borrow DAI, then buy ETH with that DAI, essentially going long ether. However, as the ether is very volatile, one need to constantly keep track of their collateralization level. When ETH is up, mint more DAI. When ETH is down, sell some of it and pay back part of the debt to avoid liquidation.

A strategy connected to MakerDAO and Uniswap can keep the CDP collateralized while minting as much DAI as possible.

Strategy parameters

Most of the strategies will have some parameters for configuration. For the portfolio rebalancing, that is the weights of each asset. For the lending arbitrage, that might be how frequent the protocols are switched. To long ether, one could specify in which range they want to keep the collateralization ratio of the CDP.

Roles

Roles describe what a role owner can do. Roles are either tied to connector or strategy. By default, a user has all the roles for each connector and strategy (i.e. can do anything), and an operator has none of the roles (i.e. can do nothing). Generally, each action has a corresponding role.

Note: connector and strategy roles are not part of the core. Some of the roles might become canonical and be used in multiple strategies, but all of them will come as extensions.

Meta roles

Meta roles define actions that modify the high-level behavior of WD. For example, “change user” and “change operator” would allow changing the addresses of the user and operator. Another example is “deposit” and “withdraw” roles.

Connector roles

Connector roles are used to define which functions of smart contracts an operator can execute. For the WETH contract, roles would be “deposit” (wrap) and “withdraw” (unwrap). A more common example would be a connector for ERC20 token (e.g. DAI) with the roles “transfer” and “approve”.

Generally, each smart contract can have a connector, and each connector might have roles. Roles are likely to represent the external functions of the contract. For example, 0x would have roles “fillOrder”, “cancelOrder”, and others.

Strategy roles

Strategy roles define which functions of the strategy an operator can trigger. Again, for each action inside the strategy, a role would exist.

Sticking to the rebalancing example, actions might be “rebalance”, “changeWeights”, and “customRebalance”. A user might give “rebalance” role to the operator, so he can perform rebalancing with the defined weights, but won’t be able to change those weights.

Safety measures

The WD features we covered so far revolve around giving some access to other accounts. However, it also makes sense to be able to limit abilities of your account as a protection against private key theft. Additionally, it would be beneficial to provide some protection from the loss of the private key. This part is heavily researched and implemented by several projects (Gnosis Safe, Argent). The cool part is that with the introduction of “role” and “connector” concepts, it becomes pretty easy to standardize such functionality to make it interoperable and untie the interface from the implementation.

The most interesting features are likely “withdraw limits”, “transfer whitelist”, “transfer delay”, and “social recovery”. Let’s see how we can implement them.

First, being able to set withdraw limits. We will go further by setting limits to any action, e.g. token transfer, trading, lending, borrowing. We do that by creating custom roles based on the reference, and removing the original roles. For transfer, we would remove the “transfer” role in the ERC20 connector and add the “transfer X” role.

Second, transfer whitelist. This is again achieved by using a custom role that will perform a check of the recipient each time the user (or the operator) tries to send the tokens.

Third, operation delay. This one should be implemented partially on the core level. The reason is that operation delay should also apply to the changing roles, i.e. there should be a delay each time user adds or removes a new role, which is done in case the user account will be compromised. After that, it’s easy to set those delays individually to each role.

Finally, account recovery. This is done by adding “change user” role to a recovery operator. The recovery account would likely be a multi-sig, where signatures might be controlled by the user, their peers, and third-party recovery services. Once the previous account is lost or compromised, recovery operator executes “change user”, setting wallet owner to a new account.

Personal proxy

WD opens another interesting use case: being able to manage your assets from the hot wallet (i.e. MetaMask) while having direct access to them only from the cold wallet. Any of the previously discussed strategy (portfolio management, lending arbitrage, etc) will be performed by the individual. This significantly improves security and usability for most of the people, as funds might be stored on a hardware or paper wallet, while they are managed from a user-friendly wallet (e.g. on mobile). The hot wallet might be compromised pretty safely as it won’t do much harm (in some cases, it will be impossible to do any harm, but of course this depends on the actual strategies used and roles set up), and a single transaction from the cold wallet will render hacked account useless.

Existing work

Two categories of projects are related to WD: smart wallets and single-purpose delegates.

Smart wallets focus on account recovery and other safety measures. Two most popular solutions that were already mentioned are Gnosis Safe and Argent.

Delegates implement a single function that is formalized and automated. The only live solution that is known to me is CDPSaver, which implements “Long ETH” strategy. Several solutions for lending are in the R&D phase (reDefi, Earn Network). Likely, some solution for rebalancing will appear.

Meta transactions are also related, although they focus on a different problem.

EIP927 describes a generalized solution to execute functions on behalf of another account, which might be a good fit for roles implementation.

Next step

Optimizing for both implementation simplicity and potential impact, we might come up with an initial version of WD.

Essentially, Fund contract would contain 4 functions: deposit, withdraw, setStrategy, setOperator. Operators would be limited to externally owned contracts. Initial strategies would revolve around portfolio rebalancing and lending arbitrage. Connectors might be 0x, Uniswap, Compound, dYdX, MakerDAO, and similar protocols. Meta roles won’t be a part of the first version.

Keepers

Many times, it doesn’t matter who is executing an action. For example, once a user sets up a portfolio with chosen weights, anyone can rebalance it. As the logic for rebalancing is fully on-chain, the operator doesn’t need any specific knowledge and can’t do any harm.

In that case, choosing a specific operator doesn’t give any advantages but introduces a central point of failure and makes the process inefficient. Instead, we can allow any account to trigger an action. Such accounts would likely be computer bots, or keepers, that scan WD accounts to find actions to trigger. Keepers would be incentivized by small monetary rewards. That would create a keeper market, which will reduce margins and make the whole system more reliable.

Of course, the keeper network won’t be able to trigger actions that require off-chain processing. For example, “lending arbitrage” using a simple on-chain strategy will likely be inefficient, as such strategy would account only the current rates, ignoring the trend and the forecast.

Keepers can participate in many strategies for multiple users at once. It’s similar to how keepers maintain overcollaterization of loans on MakerDAO, motivated by the liquidation bounties.

Conclusion

Wallet Delegate is a design of a smart contract wallet that is fund-safe and extensible. It isn’t tied to the specific application and allows to automate repetitive tasks and delegate the managing, overall improving the user experience.

The system is flexible as it allows to operate either on-chain (by the logic defined in the smart contracts) or off-chain (controlled by Robo-advisor or investment advisor).

References