Melon Dev Update — January/February 2018

First things first, Melon is live on the Ethereum mainnet and there is a Bug Bounty Fund with 500 MLN in it.

Now, hello from the Melon dev team 👩🏽‍💻👨🏼‍💻👨🏻‍💻👨‍💻👨🏻‍💻! The first 2018 Melon Manager Competition was a great success and the live deployment of the Melon protocol occurred as planned at the end of February 2018. While we were busy putting all of this together, we lacked the time to publish the January dev update. So here is a January/February dev update, where we’ll try to summarize everything that happened -the perfect read for your casual Sunday evening by the fireplace (with a hot chocolate).

PROTOCOL

• We fixed issues that were raised during our second audit and released v0.6.0 of the protocol.

[v0.6.2]

• We added the option to invest/redeem in native currency (ETH on Ethereum) and in quote asset (MLN).
• We fixed a bug that prevented state storage in the cancelOrder function.
• We fixed a bug in GAV calculation for assets decimal places different than 18.
• We enforce eslint and solium rules at build time.
• We added a centralized exchange adapter.
• We added a lot of tests.

[v0.6.4] Melon Manager Competition version

• We added new tokens to the pricefeed; tokens were deployed as ERC223 token contracts.
• We added a compliance module that only allows the manager to invest in his fund.

[v0.7.0] Mainnet deployment version

• We fixed issues that were raised throughout our third audit.
• We fixed a bug preventing emergencyRedeem for multiple assets.
• Here are the contracts used on the mainnet: OnlyManager (compliance module), MatchingMarket (OasisDex), RMMakeOrders (Risk Management). We changed the maximum number of allowed assets to 4.
• We updated the T&Cs hash required to be signed before deployment of a fund on kovan or on a mainnet.
• We enhanced our deployment process to always deploy the same set of contracts both on Kovan and on the mainnet.
• We updated our tests files and made our tests more modular using utils libraries.

OYENTE

• We added support for standard json output
• We finished running analysis on the mainnet
• We initiated our integration with Remix (in progress).
• We fixed small bugs in the code.
• We added the option to display compilation result.
• We started implementing the layout of mapping types (in progress).

MELON CHAIN

• We started putting some thoughts into design decisions for the Melon chain.
• We have been researching on generic issues aimed to improve the network performance on P2P networks: gossip membership protocols, network topology and efficient data broadcasting.

INFRASTRUCTURE

• Parity cluster: We have created a solution that leverages Terraform, Consul and other Dev-Ops tools to create one-click deployments of scalable parity clusters accessible through a single load balancer endpoint. It is the load balancer that allowed us to provide hosted Kovan nodes and to support (to a certain extent) high traffic during the Melon manager Competition on the Kovan testnet.
• Microservices: Some operations that involve complex data query can be highly consuming when done directly to the blockchain, like the ranking of melon funds. Thus, we run an off-chain microservice to provide this data to the frontend without altering the performance of the ipfs-frontend.

MELON.JS

• We released v0.6.0 that integrated protocol v0.6.2-deploy.9.
• We enhanced our promise detection in resolvePromiseObject to ensure the frontend would run properly on different browsers.
• We fixed the cancelOrder function.
• We added the possibility to connect to a local node for the frontend.
• We performed an integration with the Parity browser; this means Melon.js is now compatible with ethers-wallet but also the Parity signer, or an unlocked Parity node.
• Some nice refactoring and few architectural changes occurred in Melon.js
• We introduced the environment object, which needs to be passed as the first argument to any function interacting with the blockchain (read or write). The environment object has an api key (where we store the Parity api) and an optional account key (where we store either the account address, or the full encrypted wallet instance fro ethers-wallet). We added helper functions to getEnvironment() and setEnvironment() to cater to our frontend needs. It is a functional approach that both gives us more flexibility and allowed us to get rid of the global setup object we had so far. With this new pattern, Melon.js knows in which environment it is running : local/hosted node ? mainnet or Kovan testnet?
• We enhanced the getConfig function, which returns an object with all contracts addresses and all whitelisted assets addresses. This config object is now passed to any asset related function (getSymbol, getAddress, toProcessable, toReadable etc.). This allows Melon.js to autonomously use the right addresses for contracts and tokens, depending on which environment it is running in (mainnet vs Kovan).
• We released v0.7.0, which is the first mainnet/Kovan compatible Melon.js release.

FRONTEND

• This environment pattern introduced in melon.js allowed us to transform the ipfs-frontend into what we like to call a truly adaptive Dapp. This means the ipfs-frontend knows in which environment it is being accessed, and can adapt accordingly:

(i) If it accessed on melon.fund without any local node, it will connect to our hosted Kovan node, and will use our in-browser custom signer built with ethers.js. This in-browser strategy is not secure enough for the mainnet.

(ii) If it is accessed with a local mainnet node, from within the Parity UI (through the Parity Dapp Registry), it will connect to the mainnet and will use the Parity signer in the Parity browser. This is the recommended way to access Melon on the mainnet, as it is the most secure one.

(iii) If it is accessed on melon.fund, with a local mainnet node and the Parity Chrome Extension, it will connect to the mainnet and will use the Parity Signer extension to sign your transactions.

• We added the “slice redeem” functionnality (redeem all owned assets).
• We added an open orders table and the option to cancel orders.
• We ensured all token symbols, links and T&Cs are dynamic upon the network in use.
• [v0.7.0] We deployed the ipfs-frontend as a Parity Dapp on the mainnet (foundation network in Parity); it is accessible through the Parity UI. We also deployed it to IPFS, which is accessible at melon.fund.

DESIGN

• We finalized and launched the new website for melonport.com, with a brand new design.
• We designed some hackathon material (… coming soon!).
• We started working on the Melon ipfs-frontend UI.

Now that Melon is live on the Ethereum mainnet, we’ll be watching over our Bug Bounty fund, and will stay on the lookout for any potential issue raised. After ~2 weeks, the current version will be shut down (including the Bug Bounty fund), so that we can fix what went wrong and roll out a new version. Next tasks also include working on the design/UI/UX of the frontend, and researching the design and mechanics of the Melon chain.

If we can be of any help in assisting you in the deployment of your live fund, please let us know. If you have any feedback/suggestions for us -or just want to chat with us, please join our Gitter channel or Telegram channel.

[Check out: melon.fund | melon.email | Oyente | Melon Project Github]

• Melon Dev Team ❤

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.