Melon Dev Update — March/April/May 2018

First things first, the Melon Olympiad has been announced, you can read about it here.

Now, hello from the Melon dev team 👩🏽‍💻👨🏼‍💻👨🏻‍💻👨‍💻👨🏻‍💻! As always, the team has been working full-steam to bring you some cool updates. We recently announced the Melon Olympiad, which we spent a lot of time preparing.

As you may know, the Melon team has entered Phase III of development. For more details on what this entails, check out the dedicated blog post On to Phase III. At the end of this phase, the team aims at delivering a feature-complete and self-sustainable protocol ie. with governance built in.

GOVERNANCE

As part of Phase III, the Melon team has started working on governance issues. We spent (and will spend) a lot of time researching, thinking and debating governance solutions. Our current thinking has been summarized here. Expect more updates on this in the coming months.

DOCUMENTATION

We also started writing more documentation for what we do. We strongly encourage anyone who seeks more knowledge on Melon to visit docs.melonport.com. We have documented the current state of the protocol/smart contracts and are committed to update it as often as necessary. Feedback very much appreciated ❤ !

PROTOCOL

We have been working on the 0.8 release. Here a the main changes that we brought for this new version:

We fixed issues discovered during the live bug bunty.

We added a staking contract, which allows people to stake MLN, which is a precondition to becoming a pricefeed operator. The top 5 stakers are allowed to push pricefeed updates to the blockchain.

We implemented the idea of a “canonical pricefeed” mentioned in the previous blog post, which provides a single price to be used in all funds. The price is determined by the prices pushed by staked operators mentioned above.

We changed the way we interact with exchanges (make/take/cancel orders) to be more dynamic, and created a unified interface for calling functions across all exchanges that we use.

We began adding support for several new exchanges. 0x protocol v1 has been integrated such that a melon fund can take an order on the 0x contract (make order is not supported yet for smart contract on 0x v1). Melon funds will now be able to interact with both OasisDex and 0x relayers.

RISK ENGINEERING

As mentioned in a previous blog post, Melonport will develop a complete set of risk management modules. We have started research work on that front. We have been looking at traditional risk management models, and have been researching what would make sense for Melon funds.

We’ve came to the conclusion that in the Melon paradigm we’re not implementing risk management per say, rather are we risk engineering ie. anticipating the risk ahead of time, and handling it in the code of the smart contract. It is about being proactive vs reactive when facing a specific risk.

risk engineering = the anticipation and identification of different risks ahead of time, and the action of preventing their occurrence through code. Rules coded into smart contracts that are meant to make sure that something will not happen in the context of a Melon fund.

= the anticipation and identification of different risks ahead of time, and the action of preventing their occurrence through code. Rules coded into smart contracts that are meant to make sure that something happen in the context of a Melon fund. After a brainstorming session, we made a long list of risks that we thought could occur in the context of a Melon fund, we tried to find out if we could handle most of those risks with parametrizable templates contracts. To that end, we’ve identified and specified a risk engineering rule set that will be our foundation layer to the development of the Melon risk engineering contracts. We’ve identified about 15 rules that can reasonably be coded into smart contracts and that would fulfill the purpose of ex-ante risk management. You can take a look at our work here (still a work in progress).

OYENTE

We reduced transaction-ordering false positive.

We added overflow and underflow detection.

We added — allow-path and — remap arguments to handle problems with imported files.

We added unchecked selfdestruct detection.

We fixed assertions containing dynamic type variables

INFRASTRUCTURE

Following the recent changes on pricefeed operations on the contract level, we set up a new microservice with a pricefeed operator (PFO).

Following the integration of 0x at contract level, we had to update our liquidity provider to make markets on 2 hosted orderbooks that we wish to use on the main net (Radar Relay and ERCDex).

MELON-LAB

Monolithic repository : We started consolidating our individual JavaScript projects into a single, monolithic Git repository. The ultimate goal for this move is to further modularize the individual projects while maintaining and versioning them in bulk. Additionally, this move improves and simplifies our development workflows and allows us to simultaneously and seamlessly work on various parts of our software stack. For managing the monolithic repository, we leverage Yarn workspaces and Lerna. You can check out the different packages of the Melon-Lab here (exchange-aggregator, faucet, graphql schema, graphql server, manager-interface and melon.js).

: We started consolidating our individual JavaScript projects into a single, monolithic Git repository. The ultimate goal for this move is to further modularize the individual projects while maintaining and versioning them in bulk. Additionally, this move improves and simplifies our development workflows and allows us to simultaneously and seamlessly work on various parts of our software stack. For managing the monolithic repository, we leverage Yarn workspaces and Lerna. You can check out the different packages of the Melon-Lab here (exchange-aggregator, faucet, graphql schema, graphql server, manager-interface and melon.js). Dockerized development environment: the monolithic repository has been enhanced with a Dockerized development environment. The whole frontend software stack can now be bootstrapped and managed using a range of simple Make commands. The only requirements for running the new development environment are Docker and Docker Compose.

MELON.JS

We integrated the v0.8 beta of the protocol, which entailed some architectural restructuring for exchange integration and pricefeed interaction. You can read the changelog here.

We worked on exchange integration ; as the protocol now supports OasisDex and 0x contracts, we worked on ways to retrieve orderbooks in real-time from different relayers. Our criteria for choosing relayers was for them to have a hosted orderbook both on Kovan and on the main net. Therefore, we worked on RadarRelay and ERCDex integration. This work initially started inside Melon.js, but we then realized that should be a standalone JS library. We then exported the orderbook related functions into a standalone package: the exchange-aggregator.

; as the protocol now supports OasisDex and 0x contracts, we worked on ways to retrieve orderbooks in real-time from different relayers. Our criteria for choosing relayers was for them to have a hosted orderbook both on Kovan and on the main net. Therefore, we worked on RadarRelay and ERCDex integration. This work initially started inside Melon.js, but we then realized that should be a standalone JS library. We then exported the orderbook related functions into a standalone package: the exchange-aggregator. Exchange-aggregator: The exchange-aggregator is a convenient way to handle subscriptions to several hosted orderbooks at a time. It gives developer the option to choose which orderbook(s) he’d like to subscribe to, and then aggregate the chosen orderbook. This library leverages the power of functional reactive programming using the Rx.js library. It uses ‘Observables’ and makes it easier to compose asynchronous and event-based code. The first npm release of the exchange-aggregator is to be expected very soon. This library was created for the needs of the Melon frontend, but can really be used by anyone seeking to handle subscriptions to many hosted orderbooks at a time. This is why we decided to extract it away from Melon.js as its potential use cases are more generic.

FRONTEND

In preparation of the upcoming Paros Olympiad, we are integrating the latest melon.js and latest 0.8 protocol version on the frontend. From an aesthetic viewpoint not much changed; this integration entails large business logic changes.

on the frontend. From an aesthetic viewpoint not much changed; this integration entails large business logic changes. Data fetching through GraphQL and Apollo : so far, the data fetching logic is handled in Redux with Redux Sagas. We’ve started implementing a GraphQL Schema in an undertaking to refactor the data fetching responsibilities out of the React application layer. In the future, we will connect the React application to GraphQL through Apollo. The GraphQL Schema has been set up in a way that allows us to run it both, within a remote hosted Express server, as well as locally within the Browser in a WebWorker process. The API supports subscriptions (live updates through a socket connection / pubsub events) and we’ve already connected a range of WebSocket based exchange APIs.

: so far, the data fetching logic is handled in Redux with Redux Sagas. We’ve started implementing a GraphQL Schema in an undertaking to refactor the data fetching responsibilities out of the React application layer. In the future, we will connect the React application to GraphQL through Apollo. The GraphQL Schema has been set up in a way that allows us to run it both, within a remote hosted Express server, as well as locally within the Browser in a WebWorker process. The API supports subscriptions (live updates through a socket connection / pubsub events) and we’ve already connected a range of WebSocket based exchange APIs. Migration to next.js : we are working on migrating the frontend interface from Create React App to Next.js. The initial migration is done and the application now already runs within Next.js but hasn’t been fully ported to leverage the whole range of the ecosystem. Within the next phase, we will refactor our routing system to use the Next.js routing layer.

: we are working on migrating the frontend interface from Create React App to Next.js. The initial migration is done and the application now already runs within Next.js but hasn’t been fully ported to leverage the whole range of the ecosystem. Within the next phase, we will refactor our routing system to use the Next.js routing layer. Component library : we’ve set up a proof of concept standalone component library that we will use in the future to develop and theme our pure rendering components in isolation. The resulting components can then be imported into and used within the frontend interface and any future React base application.

: we’ve set up a proof of concept standalone component library that we will use in the future to develop and theme our pure rendering components in isolation. The resulting components can then be imported into and used within the frontend interface and any future React base application. Native desktop application powered by Electron: In an effort to provide our users with the most secure application, we worked on packaging the frontend interface as an Electron application. This will allow us to distribute the entire software stack as a simply installable, native desktop application.

DESIGN

We worked on the hackathon website .

. We created wireframes for the next version of the frontend.

for the next version of the frontend. We worked on the new frontend design (very very exciting upcoming design for the frontend!!)

(very very exciting upcoming design for the frontend!!) We worked on the design of internal documents and the design of the new Melon specifications documentation.

If we can be of any help in assisting with the Melon Olympiad, please join our Telegram channel. 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.