Two years ago, we started out on a vision to upgrade asset management; to make it more accessible, transparent and fair.
Without delving into the details of our ongoing journey, we would like to proudly announce that we now have reached an important milestone. We are releasing version 1.0 of the Melon Protocol, code named ZAHREDDINO.
Important note: An upgrade was pushed after v1.0 of the Melon Manager Interface. To download the latest software, please head to: https://github.com/melonproject/melon-lab/releases
MELON PROTOCOL V1.0
The Melon protocol is a set of smart contracts deployed to the Ethereum main net. A Melon fund itself is also a set of contracts that implement the behavior of an investment fund.
To learn more about the architecture of the protocol, check out this presentation by Travis Jacobs at M-1:
The Melon protocol allows you to:
- Set up a technology regulated and operated fund (TROF) on the Ethereum main net
- Define a ruleset which will govern the behavior of your fund: fee structure, risk engineering profile, authorized subscription assets, investor whitelist etc.
- Choose the decentralized exchanges you want to be able to trade on
- Trade against the Melon Engine
- Invest in your own fund, or in other existing Melon funds
- Redeem shares you own in a Melon fund
- Track and observe your fund’s metrics (NAV, GAV, share price all computed on-chain)
- Calculate and collect on-chain management and performance fees
- Permanently close your fund
Over the course of the past 2 years, the Melon protocol has been audited by various independent parties: Nick Johnson & Martin Swende, Least Authority, Deja Vu Security, Solidified and Matthew Di Ferrante.
Since those audits, the codebase has been refactored and the architecture reworked. The new codebase has been audited in early 2019 by two independent auditors: Solidified and ChainSecurity. Both auditing teams have found security-critical issues, all of which have since been addressed.
However, security audits are by no means a guarantee against possible vulnerabilities; the Melon protocol is still very immature and experimental and new issues could arise when users start to interact with it. We believe the protocol is still in need of more audits and further security testing for at least a couple of years before it is anywhere near production ready.
THE MELON UNIVERSE IS A STRANGE AND DANGEROUS PLACE.
The protocol codebase is very dense and complex, especially by smart contract standards. Comments from our auditors indicate that the Melon protocol is one of the most complicated projects to ever go live on Ethereum. After several audits, the last auditors still found security-critical issues. The assumption must be made that there will be more bugs.
Therefore, only advanced users are encouraged to use and test it. If you are not comfortable with smart contract interaction, we advise you to wait for the early adopters to battle test this initial version.
Do your own research! If you do decide to use the Melon software, be sure to have read and understood the documentation beforehand (https://www.docs.melonport.com/). Our codebase is open-source, so you are strongly encouraged to inspect the code that you will run (and even to get it audited further).
The Melon protocol is innovative and sometimes has an idiosyncratic way of doing things. In order to know what to expect, make sure you read the aforementioned documentation, as well as the Melonport blog.
To limit asset loss potential for non-technical users, we are capping the funds’ assets under management (AUM) at the frontend level at the equivalent of 5000 DAI per fund (not capped at smart contract level). In parallel, the Melon Council will run an ongoing bug bounty where reports of security vulnerabilities will be compensated (more on that soon …). Progressively, as the confidence level in the codebase increases, the Melon Council will lift the above user interface restriction.
This restriction is meant as a safety net, but ultimately nothing replaces user responsibility; only put at risk assets that you can afford to lose. Handle with care.
Melonport will transfer the ownership of the ENS domain melonprotocol.eth to the Melon Council shortly after the release. These ENS subdomains point to the latest official Melon contracts. Here are the subdomains you should be looking at when trying to find the latest code (you can search for them on a blockchain explorer like Etherscan):
MELON MANAGER INTERFACE V1.0
WHAT’S IN V1?
The Melon Manager Interface is the direct gateway to the Melon protocol. It is a desktop application (built with Electron) that allows non technical users to interact with the smart contracts.
This application was built with the decentralized paradigm in mind. You are able to run it entirely locally, without connection to any external server. If you run your own Ethereum node, you can connect to it. By default and for user experience purposes, the application will connect to Infura through Frame (see below) but you can change that anytime.
Using that desktop application, you will be able to set up a fund with your chosen ruleset, invest in it, and manage it by trading against OasisDex, Kyber, 0x, the Melon Engine and, soon enough, Ethfinex. If you make your fund open-ended, other users will be able to invest in it. Similarly you are able to invest in any open-ended fund. You can browse the existing Melon funds on the homepage of the app.
There is one and only one place to download the Melon Manager Interface and that is on the Melon project Github repository: https://github.com/melonproject/melon-lab/releases. DO NOT DOWNLOAD THE MELON MANAGER INTERFACE FROM ANYWHERE ELSE.
Before using the desktop application, you will need to download Frame: https://frame.sh/. Frame allows you to use hardware wallets (Trezor, Ledger) with the Melon Manager Interface. You can choose to connect to the Ethereum main network or the test Kovan network through Frame (it will use Infura endpoints by default, but you can customize that).
Once you have it downloaded and installed, make sure that the Frame app is open before you open the Melon Manager Interface.
We strongly recommend to use the Melon Manager Interface with a hardware wallet. Make sure your hardware wallet is connected to Frame and that you have enough ETH to pay for Ethereum gas and Melon gas.
Before doing anything on the Melon Manager Interface, make sure you log in through Frame. Go into the “Your Wallet” section on the top right corner, and select “Run with Frame”.
How much ether should I have on my account?
At the time of writing, deploying a fund and investing in it costs c. 0.2 ETH of asset management gas. If you use an average Ethereum gas price of 10 gwei, you will pay roughly 0.2 ETH as well. This bring the total cost (asset management gas + Ethereum gas) to 0.4 ETH. Make sure you have a balance greater than that amount in your fund. The Ethereum gas price is known to be quite volatile depending on network conditions, so make sure you check Eth Gas Station before starting.
In addition to that, make sure you have an amount of Ether or tokens you’d like to invest in your fund. If you wish to invest in your fund in ETH, you will need to wrap that ETH (convert it to WETH) because Melon funds only support ERC20 tokens at the moment. Good news, in the “My Wallet’ section, you have the option to wrap/unwrap Ether. Wrap the quantity of Ether you will want to invest in your fund in a further step.
By this point you should be logged in on the Melon Manager Interface through Frame, with an account that has at least 0.4 ETH and some WETH (or other token to invest in your fund). You’re now all set and ready to deploy your technology operated and regulated fund. Neat.
CREATE YOUR OWN ON-CHAIN FUND 101
Now that you’re set up with Frame and (hopefully) a hardware wallet, and a sufficient ETH balance, it is time to get started. If you click on “Setup fund”, you will be guided through the different steps to deploy your main-net on-chain hedge fund. Exciting.
We’d like to give more context to some of the features.
STEP 1: Name, exchanges and subscription assets
- Denomination asset: No choice to make here. By default in v1 of the Melon Manager Interface, all funds are denominated against ETH. At the smart contracts level, you are free to choose the denomination asset of your fund. You can think of the denomination asset as the base currency of your fund; all fund metrics (NAV, performance, fees etc.) are denominated in this asset.
- Fund name: only one fund name can be used per version.
- Decentralized exchanges selection: Select the exchanges you want your fund to be allowed to trade against (this is not changeable post fund creation). Right now OasisDex, Kyber, 0x and Melon Engine are fully functional. Ethfinex is on the way.
- Authorized subscription assets: Choose in which assets it is possible to invest in your fund. This is something you can come back to and change in the future. Here is the list from which you can choose the assets you accept subscriptions in: BAT, DGX, REP, ZRX, WETH, MLN, MKR, DAI, KNC.
Note on Melon Engine: The Melon Engine is fully functional. One of its specificity is that when ETH is sent to it through amgu payable functions, the ETH is frozen and every month it can be thawed. Melon funds are able to sell MLN and purchase ETH from the liquid ETH pool on the Engine (the thawed ETH).
STEP 2: Fee structure
As in the traditional asset management world, you will be able to define your management fee, performance fee, and performance fee period. To learn more about this, check out this great write-up by John Orthwein, Management and Performance Fee in a Melon Fund.
STEP 3: Configure you fund’s risk profile
By default your fund will deploy and enforce no risk management or compliance policies. Your fund will only evaluate and enforce the policies that you actively configure at a the time of fund setup. Please consider carefully each policy and the combination of policies as these choices are, by design, unchangeable for the lifetime of the fund. There are a few configuration changes that can be made to specific policies (discussed below), but for the most part, you should consider fund policies immutable.
There are five risk-related polices and one compliance related policy which are all optional and are chosen at the manager’s discretion.
Below are the currently available policies. The Risk Management policies are denoted [RM] and applied on trading (some of them also on investment). There is only one Compliance policy and it is denoted [C], applied only at investment.
Price tolerance [RM]: This policy defines the maximum (harmful) deviation in trade price from the current market price source. It is highly recommended to configure and deploy this policy as it protects investors against poor trades (accidental, intentional or otherwise), essentially giving investors a guarantee that exploitative trades cannot be engineered at current market conditions. The manager configures this policy with a number representing the percentage acceptable deviation. A low percentage like 1% will give investors a high level of protection but may be overly restrictive for trading. A high percentage like 50% will give the manager a high level of trade flexibility and choice, but offers little protection to investors as a trade could lose a maximum of 50% as compared to the market price. Trades with price deviations that benefit the fund and its investors are of course not subject to the price tolerance policy — this is all handled by the price tolerance policy logic, leaving the manager to focus on finding beneficial trades. The price tolerance policy cannot be removed from the fund, nor can the tolerance percentage be changed after deployment. All maker order and take order trades will be subject to the policy if it is deployed with the fund.
Maximum number of positions [RM -applied both on trading and investment]: This policy defines the maximum number of different asset tokens which can be held in the fund at any one time. The policy is configured with an integer representing the maximum number of underlying fund positions. This number does not consider the fund’s denomination asset token. For example, if the policy configuration is set to three, the fund can hold WETH, ZRX, DAI and DGX. To establish a holding in BAT, one of the non-denomination asset token positions would need to be fully liquidated before BAT could be added to the fund. The rationale for this policy is to constrain the manager in a way that prevent over-diversification and high trade costs associated with many small positions. For this policy to have any effect, the maximum positions configuration should be less than the Melon fund’s potential investment universe size. The maximum positions policy cannot be removed from the fund, nor can the position quantity configuration be changed. All maker order and take order trades, as well as investment requests, will be subject to the policy if it is deployed with the fund.
Maximum concentration [RM -applied both on trading and investment]: This policy defines the maximum value as a percentage of fund value that any single position can have. This policy prevents the manager from building up fund positions which represent a concentration risk, or an unacceptable level of unsystematic risk, in the portfolio. In short, it guarantees a minimum diversification level for the fund investors. The denomination asset token is not considered by this policy, as the manager must be able to allocate without restriction to the denomination asset token. If this policy is used in conjunction with the maximum positions policy, careful thought should be put into the choice of configurations and their logical implications. For example if you set your maximum positions to two, and maximum concentration is set to 10%, while possible and even intended, your fund might be 80% WETH, 10% BAT and 10% ZRX. The maximum concentration policy cannot be removed from the fund, nor can the position concentration percentage configuration be changed. All maker order and take order trades, as well as investment requests, will be subject to the policy if it is deployed with the fund.
Asset whitelist [RM -applied both on trading and investment]: This policy defines a list of asset tokens eligible for investment by the fund. If this policy is configured and deployed by the fund, the fund will only ever be able to hold positions in the asset tokens specified on the list. This policy does not consider the denomination asset token. The rationale for this policy is to present a guarantee to fund investors that only a specified subset of the Melon asset token universe is investable for the fund. The asset whitelist policy cannot be removed from the fund, however whitelist member asset tokens can be removed at a later point in time by the manager. Fund positions in asset tokens removed from the whitelist will remain unaffected, but trades after the removal will fail. All maker order and take order trades, as well as investment requests, will be subject to the policy if it is deployed with the fund. It may not be practical to deploy this policy in conjunction with the asset blacklist policy.
Asset blacklist [RM -applied both on trading and investment]: This policy defines a list of asset tokens which are ineligible for investment by the fund. If this policy is configured and deployed by the fund, the fund will never be able to hold positions in the asset tokens specified on the list. This policy does not consider the denomination asset token. The rationale for this policy is to present a guarantee to fund investors that a specified subset of the Melon fund asset token universe will never be invested by the fund. The asset blacklist policy cannot be removed from the fund, however specific asset tokens can be added to the blacklist at a later point in time by the manager. Fund positions in asset tokens added later to the blacklist will remain unaffected, but trades after the addition will fail. All maker order and take order trades, as well as investment requests, will be subject to the policy if it is deployed with the fund. It may not be practical to deploy this policy in conjunction with the asset whitelist policy.
In general, thorough and careful consideration should be given to the logical consequences of the combinations of the above risk policies and their chosen configurations. Poor policy selection and configuration may result in a fund which is too restrictive to be practical for the manager or is unattractive for investors.
Investor whitelist [C -applied only at investment]: This policy defines a list of addresses which will be eligible to subscribe to the fund. Attempted subscription transactions originating from addresses not on the investor whitelist will fail. The rationale for this policy is to grant the manager the ability to specify which addresses may subscribe to the fund. The investor whitelist policy cannot be removed from the fund, however the manager retains the discretionary ability to add or remove whitelisted addresses at any time. All subscriptions will be subject to the investor whitelist policy if it is deployed with the fund. Funds electing not to deploy the investor whitelist policy will be open to subscription by any investor.
If you run into problems, please open an issue here: https://github.com/melonproject/melon-lab/issues/new
While we advocate for a slow, cautious and progressive adoption of this software, we thought it would be nice to be able to monitor metrics such as number of funds, amgu price, ether consumed, MLN tokens burnt, assets under management on the network etc.
Meet the Melon Network monitoring tool: http://monitoring.melon.network/
The monitoring dashboard is here to help the Melon Council to inspect the activity on the network, but also really for anyone interested in watching this baby grow over time. Add to favorites ❤.
Amgu price: The initial amgu price (asset management gas price -see Melonomics 2) has been set to 0.0000001 (10e-7) MLN per asset management gas unit. As mentionned above, this brings the asset management gas cost of setting up a fund and investing in it at approximately 0.4 ETH (at the time of writing).
Pricefeed: The prices used in the Melon universe are derived from the Kyber Network; there is a pricefeed updater service managed by the Melon Technical Council that calls the update function at least once per day, to update the prices used in the Melon universe with the latest prices provided by reserve managers on Kyber. Melon Funds shall benefit from new prices every 24 hours roughly.
There is so much more to say about this release, but this is already a lot to digest. We hope that our community will be pleased with the v1.0 of the Melon protocol and its accompanying Melon Manager Interface. We have done our best to meet expectations.
Melon aims at providing an infrastructure for asset management 3.0, and thereby is part of a wider decentralized and open finance stack (#dopefi) . We had the chance to collaborate with different teams in the space, and we would like to thank all of them for their drive, dedication and support: Aragon, Kyber Network, Ethfinex, 0x, Radar Relay, ERCDex, MakerDAO, DappHub, Woorton, Gnosis and many others. Along our journey, we came across some very special individuals who supported us, and added so much value to what we were doing so we would like to thank them personally: Nick Munoz-McDonald, Adam Kolar, Janos Berghorn, Matt Di Ferrante, Dean Eigenmann, Jorge Izquierdo, Luis Cuende, Gabriel Garcia, Ferran Borreguerro, and Will Harborne. We would like to thank everyone who supported us, tested the software, showed patience and provided insightful feedback.
From the Melon dev team, with love ❤