Melonomics Part 1: Aligning Interests Through Token Unification

Melonomics addresses the Melon token economics in a series of blogs. Each part will focus on a certain aspect of token economy. Today, we will begin with Part 1, which addresses the alignment of interests across a growing ecosystem.

Issuing tokens is still the easiest way to raise funds and build a community of supporters around blockchain projects. It’s no surprise then that more and more companies are employing ICOs to fundraise, but where does this leave token users? In some cases, people might have to buy multiple tokens to use one single application. This creates inefficiencies for the user, and at a system level it means that there’s fragmentation and greater barriers to entry. Could token unification provide a solution?

How Can We Align Interests Across an Industry with so Many Tokens?

Even though we seem to be in the midst of an ICO craze, we are still seeing a significant amount of innovative companies use ICOs to fund projects. This is especially the case in the blockchain asset management space. Over the last few months, we’ve engaged with some of these projects who have shown an interest in building asset management applications on top of the Melon protocol and Melon.js to build a range of tools and applications. Just to name a few these projects include:

• Midas.Social, a decentralized portfolio management system which gamifies fund management and investing in order to make it an easy, everyday experience
• Auctus, a smart contract powered retirement platform which uses robo-advisory to build tailored pension schemes using traditional and cryptocurrency assets. More info here
• Akropolis, a technology platform which is taking on the pensions industry in a decentralized way

Each of these entities is building an asset management application and has shown interest in using Melon to underpin its project. Unsurprisingly, each of these projects is either planning to or has already launched an ICO. Projects likes these need capital to cover their running costs and issuing a token remains the easiest way to fundraise and build a network in the blockchain space.

Assuming each project has its own single native token (some may have more), most token models would require their native token to interact with their application. Additionally, interaction with the Melon protocol would require MLN tokens, and since Melon will run on the Ethereum blockchain, users would require Ether too. Consequently, in order to use one of these applications, a user would need to hold at least three different tokens.

Buying multiple tokens to use one single application is going to be inefficient, impractical and costly - and we certainly don’t want to move in that direction! It’s costly as every transaction from one token to another will incur a financial cost, but it’s also costly in terms of time and effort. This process of buying and exchanging multiple tokens isn’t exactly seamless for the user- and even if you could ‘hide’ this process from the user through a smooth interface, you would still be incurring the cost of this inefficiency in the background. In addition, the fragmentation of tokens means lower liquidity which also adds a hidden cost and inconvenience to the user. Imagine instead, there was one common asset management token.

Before, we explore these possibilities though — it is worth a reminder that Melonport has committed to a maximum inflation rate of 50%, although this estimate was recently lowered due to a perceived reduced need to incentivize module developers. It is expected that a the inflation of MLN tokens created each year will be allocated towards future maintenance & development of the Melon project.

Enabling Other Asset Management Projects to Apply for an Allocation of Melon Tokens

There could be better alignment if we establish a common asset management token, and there’s an argument for making Melon that common token going forward. But how would it work in practice?

Let’s say a project comes along with an interesting idea for an application which builds additional functionality or a use-case on top of Melon. They have a strong team, a compelling idea and all they need is the funding to make it happen. What if they could submit a proposal to the Melon Council to build that application? The proposal put forward to the Melon Council and if the majority were in favour, this project could earn the right to some Melon tokens to fund development.

Token Swaps

Assuming two tokens are already running in parallel — one can also imagine a token swap. This could be as simple as proposing a swap of one token for another to both token-holding communities. In other words, this would involve the burning of a smaller asset management project’s tokens in exchange for the issuance of new Melon tokens (created by inflation) to previous token holders. This would occur in a ratio that was agreeable to both communities conditional on it being agreed on by each independent governance system.

The logic here is that even though one token is being inflated to accommodate another, the overall benefit of gaining a new team, community of developers, users and supporters, and network effect, far outweighs the negative impact of dilution.

Example: Swapping tokens with a smaller project

Proiect X has 1,000,000 tokens in circulation which are trading at a price of $10 per token. The project has a market cap of $10,000,000. Project X token holders want to convert their tokens to Melons.

The Melon project has 1,250,000 tokens in circulation which are trading at a price of $30 per token. This gives Melon a market cap of $37,500,000.

Assuming both sets of token holders had agreed such a swap through their respective governance systems, an appropriate exchange rate swap would need to be determined. One could argue that by combining the strength of both projects you would get a total market capitalization of $10,000,000 (Project X) + $37,500,000 (Melon project) = $47,500,000. This means that $10,000,000 worth of new Melon tokens would need to be created. This would mean issuing $10,000,000/30 = 333,333 new Melon tokens in exchange for burning all of project X tokens in a ratio swap of 1 MLN granted per 3 X-token.

What happens when the market cap of the token looking to merge into Melon is larger than the market cap of Melon? This could be possible and happen on a similar basis to the above, but the swap ratio and the number of Melon tokens being issued would have to be adapted accordingly.

Token Mergers

Token mergers is an interesting one too. Imagine two projects with token market capitalisations of roughly equivalent size. Both projects have a lot of can see synergies in combining forces. Imagine both respective governance systems voted in favour of such a merger. This could result in the two projects jointly creating a new token contract and dispensing of their own respective token contracts. A token holder in either project would be entitled to new “merged” tokens in exchange for the burning of their existing ones.

What are the Benefits to Making Melon the Common Asset Management Token?

So why should Melon be the asset management token of choice? One of the main benefits of allowing projects to issue Melon tokens would be in creating a pool of projects and talent invested in building a strong, robust protocol with multiple use-cases. If projects were able to issue Melon tokens, they would have an interest in improving, maintaining and refining the protocol, as well as encouraging others to build applications on Melon. This would create powerful network effects and aligned incentives, again strengthening and growing the Melon ecosystem.

Clearly this would be of benefit to Melon users and token holders, but it has a wider benefit too. Having one common asset management token would reduce the issue of friction for users described above. One of the biggest benefits of blockchain technology in asset management and a core tenet in our design philosophy is reducing barriers to entry.

We’re still working out what the killer Melon use-case could be. Could it be robo-advisory, pension savings, social trading or something we haven’t even thought of yet? Maybe it’ll be used to invest in and manage the pension fund of the future, or to access a sophisticated asset management interface for the burgeoning digital asset space. What is clear, however, is that enabling projects to issue Melon tokens would be a major spur for innovation. It would incentivise people to come up with new ideas for applications built on Melon. Our recent hackathon highlighted a selection of great examples of what can be built using the robust Melon protocol.

Lastly, another benefit for users is that since Melon is so close to being a stable version on the main-net with clear governance structures and processes, it is likely that Melon would be considered (with more certainty than previously) as a utility token rather than a security token.

We still need to issue Melon tokens to incentivize further development, innovation and maintenance of the protocol. While this space is still largely experimental, we believe that aligning incentives and focusing resources could be in the best interest of projects working in this space, and ultimately users, going forward.

Managing risks

The main risk of issuing Melon tokens for new projects is that it could affect the quality and reputation of Melon if those projects don’t deliver. However, these risks could be mitigated by the following:

• Projects like Messari which provide validation, checks & transparency on team, vision and expenditure
• Linking distribution of Melons to delivery of certain milestones
• Establishing a standard method to evaluate the quality of a project, including risk rating criteria, for the Melon Council

Adhering to the Principle of Decentralisation

This idea of token unification should also demonstrate our belief in decentralisation; we firmly believe that the protocol should be maintained and improved in a decentralised way rather than by a central entity. Indeed, if this token unification model proves successful over time, it will dilute the importance of the original founders and participants, as well as nurture the community involved in maintaining and improving the protocol. Furthermore, this model would encourage the proliferation and diversification of people and projects involved, thereby creating a strong and stable network. With a rich community of users, developers and other stakeholders being incentivised to innovate and collaborate we will undoubtedly get better results!

Note:

The Melon protocol is a decentralized tool which is autonomous and self-maintainable. Even though we have put forward the ideas in the blog above, this does not mean we will endorse any project proposals. Our plan is to dissolve the company on completion of Phase III and form a new entity where maintaining Melon will only be a minor operation (if any) of the new company. Consequently, we are looking to maximize network effects and align interests across the industry to ensure the legacy of the Melon project.

This blog indicates our ideas as we research and implement phase III of the Melon protocol. It 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.