MIP: 5
Title: Fee Shares and Subscription Shares Segregation
Authors: John Orthwein jo@melonport.com
Status: Draft
Type: MIP
Created: 28.12.2018
Reference implementation: see general outline of options below.
Abstract
Melon funds currently create shares when capital is subscribed to the fund and when management- and performance fees are allocated. Created shares are indiscriminately added to the totalSupply_ of shares and to the balances share ledger. This MIP proposes that share creation due to fee compensation be tracked and maintained separately from share creation arising from subscriptions.
Background
Melon fund shares implement the ERC20 interface. They have a public state variable uint256 totalSupply and a mapping (address —> uint256) balances. The state variable totalSupply represents the sum of all entries in the mapping balances. The functions that create or destroy share tokens must change both totalSupply_ and balances for the share token supply state to remain synchronized and uncorrupted.
When shares are created and added to an address’s balance and to the totalSupply_, valuable information about the source and quantity of the state change, i.e. share creation reason, is lost.
Motivation
The current fee mechanism implementation requires the manager to redeem fee shares immediately upon creation in order to receive the exact, correct percentage of the fund. By not redeeming immediately, recursive fee calculation could (negligibly) skew fee results. Finally, historical lookups and calculations would be required to derive fee amounts from historical artifacts, rather than a simple current state query.
Implementation
Two feasible implementation paths, A and B, are roughly outlined here:
A:
Maintain additional, separate state variables for subscribed shares quantity, management fee shares quantity and performance fee shares quantity. The sum of these three state variables must always equal the quantity represented by the total supply state variable.
+ provides granular information on the amount of manager subscribed shares, management fee shares created and performance fee shares created for easy, transparent audit.
+ keeps a single, clear manager address (no complexity overhead of managing a separate manager fee vault contract)
- requires variable maintenance functionality to increase variable values on fee allocation and more sophisticated logic decrease variables when manager share redemption amounts are greater than manager subscribed amounts, but less the total manager shares (i.e. manager’s subscription shares plus fee shares).
B:
Create a separate fee vault contract, controlled by the owner, i.e. manager address.
+ very little impact to shares/fees code; mint fee shares to the new contract address
- management and performance fees are not separated - general fee amounts are known, but information on the breakdown between management- and performance fee share quantities is lost.
Abstract
Melon funds currently create shares when capital is subscribed to the fund and when management- and performance fees are allocated. Created shares are indiscriminately added to the totalSupply_ of shares and to the balances share ledger. This MIP proposes that share creation due to fee compensation be tracked and maintained separately from share creation arising from subscriptions.
Background
Melon fund shares implement the ERC20 interface. They have a public state variable uint256 totalSupply and a mapping (address —> uint256) balances. The state variable totalSupply represents the sum of all entries in the mapping balances. The functions that create or destroy share tokens must change both totalSupply_ and balances for the share token supply state to remain synchronized and uncorrupted.
When shares are created and added to an address’s balance and to the totalSupply_, valuable information about the source and quantity of the state change, i.e. share creation reason, is lost.
Motivation
The current fee mechanism implementation requires the manager to redeem fee shares immediately upon creation in order to receive the exact, correct percentage of the fund. By not redeeming immediately, recursive fee calculation could (negligibly) skew fee results. Finally, historical lookups and calculations would be required to derive fee amounts from historical artifacts, rather than a simple current state query.
Implementation
Two feasible implementation paths, A and B, are roughly outlined here:
A: Maintain additional, separate state variables for subscribed shares quantity, management fee shares quantity and performance fee shares quantity. The sum of these three state variables must always equal the quantity represented by the total supply state variable.
+provides granular information on the amount of manager subscribed shares, management fee shares created and performance fee shares created for easy, transparent audit.+keeps a single, clear manager address (no complexity overhead of managing a separate manager fee vault contract)-requires variable maintenance functionality to increase variable values on fee allocation and more sophisticated logic decrease variables when manager share redemption amounts are greater than manager subscribed amounts, but less the total manager shares (i.e. manager’s subscription shares plus fee shares).B: Create a separate fee vault contract, controlled by the owner, i.e. manager address.
+very little impact to shares/fees code; mint fee shares to the new contract address-management and performance fees are not separated - general fee amounts are known, but information on the breakdown between management- and performance fee share quantities is lost.