Melon project: On to phase 3
The Melon project is almost 2 years old, and the first live version of the protocol was deployed recently to the Ethereum network. We thought this was a good time to provide our community with a progress update.
Here is the roadmap that was published over a year ago by Mona El Isa and Reto Trinkler:
Phase I: PoC2 — will be completed and released before the start of the initial token sale.
Phase II: Moving from PoCs to first live release. We will focus on getting the Melon protocol up and running on the Ethereum main network allowing Users to set up portfolio structures and trade ERC20 tokens within the parameters of the portfolio in a completely decentralized way. The first live release will include, the core smart contracts and a full suite of modules. The modules will fall under the following classes: Price feeds, Asset universe (or trading registrar) modules, Exchange, Risk management, Performance & Management fees.
Phase II will also consist of two security audits, a bug bounty programme, a Melon formal specifications document and a basic functioning UI.
Phase III Here, we will focus on finalising the governance structure and deploying the Melon protocol in its entirety. This will complete Melonport’s workshop function and handover the Melon protocol and its governance to Melon token holders. We also plan to use funds to ramp up and improve the front end of Melon as well as marketing and communications budget around the project helping us build strong partnerships key industry players in the financial space.
Phase 1 was completed at the time of publishing the roadmap. We are now proud to announce that phase 2 was successfully completed:
- The Melon smart contracts underwent three independent audits.
- The first live version of Melon has been deployed to the main network.
- A live bug bounty fund with 500 MLN was live for 3 weeks.
- A new version of the Melon formal specification is being worked on and will be published as soon as they are ready.
- The Melon frontend is fully functional and usable both on the Kovan testnet and on the mainnet (deployed to IPFS and as a Parity Dapp).
What has changed?
If you’ve been following the project, you might have noticed that things often change; that’s true. We move fast, break things, question our approach and iterate over. This is for us the way forward to building a truly decentralized asset management system. We want to keep our community updated on our latest thinking. Here are the latest changes that we are currently building into the protocol (please keep in mind Melon is in constant evolution and any of the below could be subject to future changes, as we are still researching those points):
- There are now only 2 categories of modules: Compliance (participation in a fund) and Risk Management. Throughout the development of the protocol, some modules categories turned out to be unnecessary (eg. management/performance fees now integrated in the Fund Contract ) or too security sensitive (eg. Pricefeed).
- There will be one canonical Asset Registrar for the whole Melon ecosystem, associated with a canonical Pricefeed.
- We envision a limited number of pricefeed operators (as of now, 5), who would each run their own pricefeed. The median prices of the 5 pricefeed operators then get pushed to the canonical Pricefeed. The pricefeed used for fund valuation and risk management module is the canonical Pricefeed.
- Give the option to investors to invest/redeem in a Melon fund using any ERC20 token as well as the native asset of the chain (ETH).
- We introduce a maintenance fee, which will be collected across all existing Melon funds, in proportion of AUM and function of time. The maintenance fee will reward the active token holders for their governance efforts. Part of it may or may not be used to compensate for the cost of operating the canonical Pricefeed.
We are now entering Phase 3 of development, which consists in bringing improvements to the protocol and work on the governance structure of Melon. The goal of Phase 3 is to deploy not only a decentralized protocol but also autonomous and self-sustainable asset management system. Here is our current approach regarding governance (again, subject to future research and further changes):
- Token holders can submit protocol improvements proposals
- Token holders elect technical council, which:
(i) Selects assets to be included in the asset registrar.
(ii) Approve/disapprove prices pushed to the canonical Pricefeed (security feature). It can disapprove prices if deemed wrong, and punish the pricefeed operators by burning part of their stake if they repeatedly fail on providing prices and/or provide wrong prices.
(iii) Decides on Melon Smart Contracts upgrades unless a protocol improvement proposal is submitted by the Token holders directly.
- Maintenance fee in % of AUM and compounded over time, to reward active token holders (active has yet to be defined).
From now on, we’ll be researching and working on governance, protocol improvement as well as optimization. We will try to keep updating our community as often as possible on upcoming evolutions.
Bug bounty findings
On another note, we ran our first live bug bounty program on the Ethereum main net in a hope for anyone to try to extract the assets of our fund. No vulnerability allowing someone to drain the assets out of the fund was exploited.
However, that experience was very insightful as we stated that we would compensate any valuable bug report, even if one didn’t manage to drain the fund. That allowed people who found non immediately exploitable vulnerabilities or bugs unrelated to draining the funds to be eligible for a reward if they reported the bug by email to us. We had a great vulnerability report by Nick Munoz-McDonald who discovered that a malicious shareholder could potentially steal all assets held by the fund.
The vulnerability is as follows: A malicious investor could call the function
emergencyRedeem where the parameter
requestedAssets is an array of fund held asset addresses each repeated n times, and n for each address is selected such that
quantityHeldInFund ≥ (n * assetHoldings * shareQuantity) / totalSupply .
Here is a good example given by Nick: assume a given fund holds 10 units of asset A in the fund contract. User Charlie holds 2 shares of 10 total fund shares. Charlie calls `emergencyRedeem(2, [address(A), address(A), address(A), address(A), address(A)])`, and is transferred all 10 units of asset A.
This constitutes a high severity vulnerability. The fix to that issue is actually simple: insert a check that the same address cannot be passed more than once to the
The issue could not be exploited in the context of the live bug bounty since one of the deployment settings for the funds was that only a fund manager could invest in his own fund -no external investor were allowed.
The whole team would like to thank Nick for his precious input, and will reward him with MLN tokens for his vulnerability report. At the time of writing, the issue has been fixed, and the fix will be (obviously) included in the next release. This experience also allowed us to discover solidified.io, the smart contract auditing platform that Nick uses; this is a company we will consider for future audit, as we would love to keep collaborating with Nick.
This blog post is subject to change as the research & development phase is ongoing. Melonport will aim to update blog-posts regularly to represent our latest thinking on a best-efforts basis but there may occasionally be time-lags between latest thinking and updated documentation. With this in mind, the author of this blog assumes no responsibility or liability for any errors or omissions in the content of this blog.