search

enzymefinance / enzip

Enzyme Improvement Proposal
https://github.com/enzymefinance/ENZIP
8 stars 11 forks source link

MIP3 - Contract-Owned Melon Funds #3

Closed lsaether closed 1 year ago

lsaether commented 6 years ago

Contract-Owned Melon Funds

MIP: 3
Title: Contract-Owned Melon Funds
Authors: Logan Saeher <logan@chronologic.network>, Daniel Kmak <daniel@chronologic.network>
Status: Draft
Type: MIP
Created: 29/06/2018
Reference implementation: TBD

Abstract

We propose that smart contracts be allowed to be owners of Melon Funds.

Background

A step toward autonomous funds, such as the PoC we demonstrated during the Reinvent Finance hackathon, is to allow smart contracts to be the owner of Melon Funds. Currently, the restriction is that the owner of a Melon Fund be an account controlled by a private key, since deploying a new Melon Fund involves checking the signature from msg.sender.

Motivation

The ChronoLogic team created an on-chain stop-loss feature using our own Chronos set of smart contracts to handle the scheduling of the stop-loss. The major barrier that we faced during the PoC integration was that Melon Funds were not able to be deployed with a contract as an owner. In order for the Scheduled Transaction that Chronos deploys to be able to initiate buys or sells of the assets held in a fund, it would be neccessary they operate through a smart contract, such as a Proxy Wallet.

Another use case is that this would allow multisig wallets to be owners of Melon Funds.

Implementation

One idea is to remove the signature requirements for the creation of a Melon Fund from the Version contract which is currently the blocker for a smart contract to deploy a Melon Fund. The other idea is to abstract the owner check one layer up so that a contract may provide the signature for it's owner instead.

Removing the signature requirement

Currently, in Version.sol to deploy a new fund the function termsAndConditionsAreSigned will be called which checks that the msg.sender of the transaction has provided a v, r, s signature on the hash of the constant TERMS_AND_CONDITIONS. This proves to be a problem if we intend a smart contract to deploy the Melon Fund as smart contracts are unable to create signatures. Examples of cases in which we might desire a smart contract to be the owner of a Melon Fund may include more than just for the Proxy Wallet of Chronos, but can include cases of multisig wallets being owners of funds as well.

The simplest solution would be to remove the on-chain checking of the Terms and Conditions and to handle this in another way.

However, it might be desired for the Term and Conditions to be signed on-chain. In that case, we can propose that the signing be allowed to be abstracted to one degree. So that the check for the Terms and Conditions are signed can check if the msg.sender is an account or a contract, if it is a contract it checks if it has the standard OpenZeppelin Ownable interface and the public parameter owner available. The ecrecover check is then performed against the Ownable(msg.sender).owner() address instead of the msg.sender directly.

Note: This MIP reflects what we believe to be the minimum amount of change to make to the Melon smart contracts to allow the Chronos integration to take place. We plan to follow this MIP with a full spec of the integration.

travs commented 6 years ago

@lsaether Thanks a lot, Logan, for this MIP. I think we all agree that this would be an excellent feature to have, and the two methods you described are certainly technically viable.

Right now, I would opt for the latter option of signing on behalf of a smart contract which owns the Fund, since it still allows one to prove that the T&C hash was at least signed by someone responsible for deploying the "manager" smart contract.

Caveats

We have to consider the possibility that the manager contract's owner changes as well, and be sure that this does not render the initial signing meaningless. If a similar signature check is applied before crucial fund actions, and not just at setup, then changing the owner would invalidate the signature and disable these Fund actions for the manager contract. This might also provide an elegant way to change ownership of a manager contract, where the new owner has to assign to accept responsibility.

I think the secondary question here (perhaps outside the scope of this issue) is a legal one: how much liability does a user signing a T&C hash lift from Melonport in our current scheme, and does adding another layer of indirection change this at all (i.e. does an "owner" of a smart contract signing on its behalf inherit liability).