schmidsi
commented
6 years ago As discussed offline I want to state some considerations/inputs here:
- I like the concept of immutability and I think we should adhere to that as much as possible. I.e. a fund set up with a certain set of rules should never change. The problem with mutable policies is governance: How can investors be informed and their consent collected when or if policies changes? This is almost impossible in my opinion. And arguments like: "It is the responsibility of the investor to know whats going on" or "If an investor doesn't vote in 30 days we see this as agreement" are against the trustlessness of the system.
- Can you make an example when a policy should change?
- Same for warning policies: Can you make an example?
I'm more in favor of atomic/immutable setups which can get replaced:
-
Lets say Alice sets up a fund with a limited whitelist of assets
-
Bob invests in this fund
-
After a while, Alice wants to add more assets to this whitelist
-
Instead of just changing the policy without Bob knowing, she creates a new fund and marks the old fund as deprecated and the new fund as successor. -->
- Her track record can be migrated from the old fund to the new fund
- Bob has a choice if he wants to upgrade or not
-
One reason in the classic fund world to have open policies is possibly to costs to create a new fund. Therefore if one invests that much of time, money and energy to setup a fund it should have a longer lifespan. But since it is so cheap to setup a new fund, this argument vanishes.
-
Another argument is trickery: If marketing material does state other facts than the actual legal texts, I see this as deceit.
Furthermore, immutability keeps a system much easier to reason about in general. But that is almost philosophic ;)
perhamgirl
Abstract
This MIP would create a hierarchy for Melon Fund Risk Engineering Policies: how they are enforced and how they may be changed.
Background
The initial concept of Melon Protocol Risk Engineering was to define inviolable policies at fund inception which could not be changed. This was by design so as to demonstrate the enforced discipline of blockchain smart contracts. Certain Risk Engineering policies and policy parameters, however, may lend themselves to such permanence, while others may not. The design goal of this MIP is to offer flexibility to the Melon Fund creator to define the nature of the Melon Fund Risk Engineering policies and/or policy parameters.
Motivation
Over time, many things may change: investment environment, classification of specific tokens, discovery of malicious tokens, risk appetite, etc. Having to commit irreversibly to blockchain enforced smart contract rules my be too severe for certain rules or management purposes. If a Melon Fund creator (Investment Manager) is to commit to risk engineering rules for the Melon Fund, they may choose very liberal parameters, which demonstrates their implementation, but ameliorates their efficacy. A similar phenomenon happens in the legacy fund environment: Legal documents are specified with very broad criteria, which legally permits certain fund actions, even as marketing material or reports claim tighter criteria. In the worst case, given the choice between immutable policies and not having the policy, a manager may choose the latter.
In order to prevent this behavior, it may make sense to provide hierarchy where Risk Engineering Policies can be specified as:
Mutable Warning Policy - The breaching action is permitted, but a warning is fired and stored on the blockchain for audit and reference. The Warning Policy or Warning Policy Parameters may be changed (including deletion), which is also recorded on the blockchain.
Immutable Warning Policy - The breaching action is permitted, but a warning is fired and stored on the blockchain for audit and reference. The Warning Policy may not be changed.
Mutable Policy - The breaching action is not permitted and will fail transactionally on the blockchain, serving audit and reference purposes. The Policy or Policy Parameters may be changed (including deletion), which is also recorded on the blockchain.
Immutable Policy - The breaching action is not permitted and will fail transactionally on the blockchain, serving audit and reference purposes. The Policy may not be changed.
Mutable/Immutable Parameter - Not required, as an Immutable Parameter in a Mutable Policy could be trivially circumvented by deleting and recreating the policy. Also, Mutable Parameters in Mutable Policies are implicit.