MIP: 6
Title: Performance Period Standardization
Authors: John Orthwein <jo@melonport.com>
Status: Draft
Type: MIP
Created: 04.01.2019
Reference implementation: TBD
Abstract
As with legacy funds, a Melon fund can be started at any date and time. However, for comparison analysis purposes, it is convenient to measure fund performance along standardized time periods, such as a specific day, week, month, quarter or year. This MIP seeks to devise a method to enable the convenient choice of performance measurement period to ease comparative analysis.
Background
Melon funds exist entirely on the blockchain within smart contracts where there is no concrete concept of the “month of July”, “Q1” or the “year 2018”. State changes happen discretely and imprecisely across time. A state change happens at the point in time where the specific block is mined and the transactions (state changes) described within that block become final. Each block records the UNIX Epoch time timestamp and is based on UTC time. This provides a reasonable basis to reference the passage of time in a global system. As there is no compelling reason to introduce this complexity to the underlying blockchain smart contracts, this MIP proposes only changes to the front-end and front-end logic layers to enable a user to specify precise but arbitrary start dates, end dates or time intervals.
Motivation
Investment decision is broadly about deploying capital to the best performing investment for a given amount of risk. In order to compare and rank investment opportunities, it is necessary to have consistent timeframes for each investment horizon under analysis. For example, an investor may be interested to see how two opportunities compare over the calendar year 2008 (to see how investments faired during a global crisis) or the arbitrary quarter Q2 2015.
Implementation
On the front end, users can arbitrarily specify a start date, end date or time interval over which the user wishes to see investment performance metrics, such as return or volatility. This can be achieved with any manner of date/time choice elements. These choice are then translated to UNIX Epoch time seconds used to query and return data from the blockchain.
One issue to overcome is the fact that there is no (second-granularity) continuous record of investment returns. Ethereum blocktimes currently target 14 seconds, but are not precise. This means that a desired start datetime, end datetime or investment interval most probably will not coincide with a specific blocktime. For example, if a user specifies an end datetime of March 31, 2018 23:59:59 UTC - corresponding to an end datetime of March 2018 and also the end datetime of Q1 2018 - the UNIX Epoch timestamp would be 1522540799 (target time). However, the last discrete observation of the state in March 2018 was block number 5357794, 2 seconds before the technical end of the month:
Block # 5357794 Mar-31-2018 23:59:58 UTC
Target time: Mar-31-2018 23:59:59 UTC
Block # 5357795 Apr-01-2018 00:00:05 UTC
Two options exist for the choice of which block to use: A) use the block state with the block timestamp closest (in absolute terms) to the target time, or B) use the block state of the block with the last timestamp still within the target time’s day, month, quarter, half or year, e.g. Block # 5357794 here. This MIP recommends option B with the argument that the block existed before the target time and not in the new, next time period.
Example: Hypothetical fund XYZ has an (arbitrary) inception date of Jan-09-2018 21:04:31 UTC in Block # 4881794.
XYZ NAV & Period Performance
DateTime
Block #
NAV
Performance
Note
Jan-09-2018 21:04:31 +UTC
4881794
1.00
0.00%
Fund Inception
Jan-31-2018 23:59:52 +UTC
5008421
1.04
4.00%*
Month End
Feb-28-2018 23:59:58 +UTC
5174124
1.02
-1.92%
Month End
Mar-31-2018 23:59:58 +UTC
5357794
1.01
-0.98%
Month, Quarter End
Apr-30-2018 23:59:45 +UTC
5534862
1.03
1.98%
MonthEnd
May-31-2018 23:59:39 +UTC
5710963
1.05
1.94%
Month End
Jun-30-2018 23:59:46 +UTC
5883489
1.06
0.95%
Month, Quarter, Half End
Month
Performance
January 2018
4.00%*
February 2018
-1.92%
March 2018
-0.98%
April 2018
1.98%
May 2018
1.94%
June 2018
0.95%
Quarter
Performance
Q1 2018
1.00%*
Q2 2018
4.95%
Half
Performance
H1 2018
6.00%*
*Footnote explaining that inception is Jan-09-2018 21:04:31 +UTC and that therefore, stated performance only represents the partial period (month, quarter, half or year).
Abstract
As with legacy funds, a Melon fund can be started at any date and time. However, for comparison analysis purposes, it is convenient to measure fund performance along standardized time periods, such as a specific day, week, month, quarter or year. This MIP seeks to devise a method to enable the convenient choice of performance measurement period to ease comparative analysis.
Background
Melon funds exist entirely on the blockchain within smart contracts where there is no concrete concept of the “month of July”, “Q1” or the “year 2018”. State changes happen discretely and imprecisely across time. A state change happens at the point in time where the specific block is mined and the transactions (state changes) described within that block become final. Each block records the UNIX Epoch time timestamp and is based on UTC time. This provides a reasonable basis to reference the passage of time in a global system. As there is no compelling reason to introduce this complexity to the underlying blockchain smart contracts, this MIP proposes only changes to the front-end and front-end logic layers to enable a user to specify precise but arbitrary start dates, end dates or time intervals.
Motivation
Investment decision is broadly about deploying capital to the best performing investment for a given amount of risk. In order to compare and rank investment opportunities, it is necessary to have consistent timeframes for each investment horizon under analysis. For example, an investor may be interested to see how two opportunities compare over the calendar year 2008 (to see how investments faired during a global crisis) or the arbitrary quarter Q2 2015.
Implementation
On the front end, users can arbitrarily specify a start date, end date or time interval over which the user wishes to see investment performance metrics, such as return or volatility. This can be achieved with any manner of date/time choice elements. These choice are then translated to UNIX Epoch time seconds used to query and return data from the blockchain. One issue to overcome is the fact that there is no (second-granularity) continuous record of investment returns. Ethereum blocktimes currently target 14 seconds, but are not precise. This means that a desired start datetime, end datetime or investment interval most probably will not coincide with a specific blocktime. For example, if a user specifies an end datetime of March 31, 2018 23:59:59 UTC - corresponding to an end datetime of March 2018 and also the end datetime of Q1 2018 - the UNIX Epoch timestamp would be 1522540799 (target time). However, the last discrete observation of the state in March 2018 was block number 5357794, 2 seconds before the technical end of the month: Block # 5357794 Mar-31-2018 23:59:58 UTC Target time: Mar-31-2018 23:59:59 UTC Block # 5357795 Apr-01-2018 00:00:05 UTC Two options exist for the choice of which block to use: A) use the block state with the block timestamp closest (in absolute terms) to the target time, or B) use the block state of the block with the last timestamp still within the target time’s day, month, quarter, half or year, e.g. Block # 5357794 here. This MIP recommends option B with the argument that the block existed before the target time and not in the new, next time period. Example: Hypothetical fund XYZ has an (arbitrary) inception date of Jan-09-2018 21:04:31 UTC in Block # 4881794. XYZ NAV & Period Performance
*Footnote explaining that inception is Jan-09-2018 21:04:31 +UTC and that therefore, stated performance only represents the partial period (month, quarter, half or year).