Everything you always wanted to know about Melon but were too afraid to ask

This is a summary of our writings on the MLN token economics: you can read the full blogs here: Melonomics 1, Melonomics 2 and Melonomics 3.

Aligning interests through token unification

Issuing tokens through ICOs is still the easiest way to raise funds and build a community of supporters around blockchain projects. But where does this leave token users? In some cases, people have to buy multiple tokens just to use one single application. This creates significant friction for users and hinders adoption.

In Melonomics Part 1, the Melonport team explains why using MLN as the common asset management token — what is referred to as ‘token unification’ — would be beneficial to all users since it would reduce friction and cost on the network, whilst incentivising teams and developers to develop the Melon protocol by giving them the opportunity to tap into the MLN inflation pool to fund themselves.

How would token unification work in practice?

New projects wanting to use MLN as their native token or simply obtain funding would submit a proposal to the Melon Council who would then vote on whether or not this project should be funded from a limited pool of MLN inflation. For existing projects, options could include mergers or token swaps.

What are the benefits of token unification?

• The ecosystem can benefit from the synergies of sharing and maintaining a common infrastructure
• It creates a pool of projects and talents invested in building a strong, robust protocol with multiple use cases. This creates powerful network effects and aligned incentives, thereby strengthening and growing the Melon ecosystem.
• It dramatically reduces friction to the users.
• It acts as a spur for innovation, incentivising people to come up with new ideas for applications built on Melon.

MLN vs Ether?

However, as long as Melon remains on Ethereum, some friction still exists. Users have to own both Ether and MLN tokens in order to use Melon on Ethereum. This is already one token too many! To overcome this problem, the Melonport team came up with the idea that users should be able to interact with the Melon Protocol while only holding and transacting with Ether, thereby creating a truly seamless experience for the user. In Melonomics Part 2 the Melon team explains how this could work: users would be charged an initial fee (Network Transaction Fee) in Ether which would cover both Ethereum gas costs and the costs of using Melon’s asset management software. The Network Transaction Fee would be split into two components:

1. Ethereum gas — the cost of using Ethereum’s computing power
2. Asset management gas — the asset management gas paid to the Melon network

The Ethereum gas goes to the miners as usual, and the asset management gas is sent to a special smart-contract forming part of the Melon Protocol, the Melon Engine.

The Melon Engine

The Melon Engine serves two purposes:

• The first is to collect the asset management gas in Ether and convert it from Ether into MLN. The Engine price will typically buy MLN at a premium to market price which is made available to users of the asset management network.
• The second purpose of the Melon Engine is to simply burn the acquired MLN tokens, effectively removing the tokens from the total token supply.

This has two effects. The first is that it creates a native “buy” demand for the MLN token which is purely linked to usage of the network. The second is that the Melon engine reduces the total supply of MLN according to the level of usage of the Melon protocol, thus providing a token sink.

One interesting variable in this model is the Melon gas price. This can be set in the Melon Engine contract and re-adjusted based on levels of usage of the protocol and the total amount of MLN in circulation. The Melon gas price should be set in such a way that it is cheap enough to encourage people to use the Melon Protocol (cheaper than traditional asset management activities) while at the same time incurring a reasonable cost to the user in order to incentivize maintainers and benefit token holders. We are still in the process of finalizing the set of functions that are amgu payable. As it stands, the following functions are amgu payable: setupFund, requestInvestment, executeRequest and claimFees. Note that trading functions are not amgu payable.

The ability to adjust Melon gas price is critical since it creates the possibility of making the asset management network cheaper as it grows (incentivising users) whilst having a continuously growing demand for Melon token and a stronger purchasing power over time (incentivising token holders to hold). The initial Melon gas price will be set by Melonport AG before deployment in February. It will then be in the hands of the Melon Council to adjust the amgu price when necessary. According to Melonport’s modeling, the Melon gas price should not need frequent adjustment. However, the 2 scenarios where we can expect an adjustment would be:

• Overnight spike in network usage
• Extreme volatility on MLN/USD

The Velocity Problem

Most, if not all, payment token models suffer from what is sometimes referred to as the ‘velocity problem’. This is typically when velocity of the token is high, therefore negatively impacting the purchasing power of the token. Addressing the ‘velocity issue’ is one of the big benefits of the Melon Engine.

In the typical ‘high velocity’ model, the tokens used to purchase goods and services are recycled back into the token economy and will most likely follow the same cycle repeatedly, as demand for the goods and services grows. These types of models fail to link the growth of the network to the value of the token. Therefore, all other things being equal, even though the number of transactions can go up massively as user engagement grows, the token simply circulates more rapidly among the community, failing to spur any price appreciation. The token inflation required to incentivize developers and maintainers therefore has the effect of sending the token into a downward price trend (all other things being equal).

In other words, it is a common misconception that increased network usage will necessarily lead to increased token price since this ignores the potential for rapidly rising token velocity.

The Melon Engine, in contrast, acts as a brake on velocity. By buying the MLN token on behalf of the user and then burning it, velocity of token circulation is directly limited (since burned tokens can’t circulate any more). To the extent that the link between usage and velocity is severed, and that usage growth must show up in price appreciation, the token will be seen as viable and therefore desirable to maintainers, developers and holders. This incentive structure can be expected to further reduce velocity, indirectly. Moreover, to the extent that the Melon engine provides a constant bid for the token, thus enhancing liquidity of the token, the incentive to own the token in the first place is (paradoxically) increased. This can further be expected to lower velocity, even as platform usage grows.

The Melon Engine attempts to ensure that once Melon governance is fully rolled out, there will be:

• A demand for the token which is directly proportional to the computational requirements of the asset management functionality on the Ethereum network
• A burn rate which is linked to the usage of the network (token sink) which lowers velocity in the lifespan of a token (and can be adjusted through periodic re-setting of the Melon gas price when necessary)
• A higher holding period for people who genuinely want to have exposure to the value of the network or its potential for adoption

Why does this matter?

Melonomics uses a traditional economic framework (quantity theory of money) to achieve the goals of creating demand for the Melon token which is directly linked to the usage of the Melon protocol as well as incentivising developers and maintainers, and removing friction for the user.

Significantly, and in contrast to other token models, this model will ensure that the value of Melon tokens is linked to user adoption whilst keeping it affordable through the asset management gas price, thereby incentivising token holders, future developers and maintainers of the Melon protocol. It essentially addresses the ‘velocity problem’.

The Melon Engine achieves this goal by creating a “buy” demand for Melon tokens linked to the usage of the network. It uses collected Ether to buy-and-burn Melon, thus providing a sink for tokens. All this is achieved without the user ever needing to physically purchase or hold Melon. This ensures that increased usage of the protocol benefits the token holders and makes room for possible inflation needs, whilst reducing friction for the user.

The ‘buy-and-burn’ model aims at providing strong economic characteristics to the MLN token which are linked to the usage of the network. This paves the way for token unification in the on-chain asset management ecosystem by aligning interests between token holders, users and developers alike. Token unification can provide the basis for innovation and growth across the whole blockchain based asset management industry as more asset management 3.0 projects align behind the same token and develop an array of novel use cases for the token.

Projected inflation and token supply

In Melonomics 3, Melonport sets out the plan for the remaining MLN tokens, and what the future holds for MLN supply and inflation. At the time of writing, there are 1,002,000 MLN tokens in circulation. There are currently 69,388 MLN tokens which have already been minted, but haven’t been distributed yet. In February 2017, Melonport AG had planned to issue 500,600 Melon tokens to the public before February 2019. Of these tokens, Melon has only issued 252,600 leaving 248,000 tokens that are yet to be issued. Melonport AG has decided to burn these 248,000 MLN tokens.

In February 2017, Melonport AG committed to a maximum yearly inflation rate of 50% for MLN tokens. The purpose of this inflation is to fund future development and maintenance of the protocol. Melonport AG has now decided that 300,600 MLN tokens will be issued each year. Since a fixed amount of MLN will be issued each year, the inflation rate will actually decrease every year, making MLN a disinflationary token (ie. the inflation rate decreases over time). You can see the projected inflation over years here. The net inflation of the MLN token is the difference between 300,600 (yearly fixed inflation) and the number of MLN tokens burnt via the Melon Engine and/or the Melon Council. If you would like to play around with numbers, we uploaded a simple simulation playground, where you can tweak variables and see the effect of the inflation combined with the burn effect of the Melon Engine. Head over here, download the file and have fun.

We hope this summary has answered all your questions about token unification, the Melon Engine and supply and projected inflation. If you have more questions, please join our Telegram channel, we’ll be happy to answer. As always, we’d be delighted to receive any constructive comments and feedback. This model is subject to further research and therefore will most likely evolve over time.