This blog post is a draft outline showing how the Melon protocol ecosystem should behave with regard to its participants assuming rational economic agents within the Melon ecosystem.
This post will also touch on how the design of the protocol architecture currently under development shall work to insure that those incentives remain aligned to the goal of the continued success of the ecosystem.
- All assets in Melon portfolios are liquid and tradable and therefore have regular, reliable price feeds
- For this version of the melon protocol the price feed is calculated with a Cryptocompare price feed module — price is determined using this methodology. We assume this to be the true price of the underlying crypto asset
The Various Economic Agents Within The Melon Ecosystem:
Melonport: The legal entity that has and continues to conceptualize and develop the Melon protocol. The Melon protocol seeks to build an open source protocol based on Ethereum smart-contracts that enables users (hereinafter also participants) to set up, manage and invest in digital asset management strategies in a way that reduces barriers to entry, minimizes the requirements for trust while maximizes transparency (“Melon protocol”).
Suppliers: a set of individuals or entities who link their existing products to the Melon protocol ecosystem (module developers) or alternatively develop products specifically for the Melon protocol ecosystem. Within this subgroup we identify two types of ecosystem players:
- Developers: people or entities that build smart-contract modules which interact with the Melon ecosystem.
- Operators: people or entities that operate these modules. For example a price feed operator, delivering price feed data to the blockchain.
Token holders: a set of individuals or entities who own the Melon tokens. These can be loosely categorised into two subsets:
- Benevolent players: Those who generally want to see the value of the ecosystem grow and thrive.
- Malevolent players: Those who have an incentive to hurt the value of the ecosystem.
Managers: a set of individuals or entities that set up and manage their own Melon fund using the Melon protocol.
Investors: a set of individuals or entities that participate/invest directly into funds (or funds of funds) which are built by Managers using the Melon protocol.
The Design of Melon Protocol
At the very top of the design architecture, we have the owners of the protocol, the Melon token holders. The Melon protocol as a software infrastructure, is (through an implemented set of rules) designed to provide protection to investors in Melon funds.
Token holders are represented by the crypto Melon token .
There are two types of functionality within the Melon protocol ecosystem.
1. Usage Functionality
When investors want to interact/invest in a Melon fund, they participate by using Melon tokens. A user would have to send Melon token to the Melon fund contract. In return, the Melon fund contract would create new shares in the fund and send the proportionate number of shares in the fund back to the investor. The fund tokens would represent the underlying assets being held in the Melon fund contract. These assets are redeemable at any time by the investor.
In terms of usage functionality of the Melon token, transaction (licensing) fees will initially be set at zero with the possibility for token holders and investors to later (once there is widespread adoption) introduce them.
This means that Managers shall be in a position to use the Melon protocol completely free of charge, but would need to use the Melon token to withdraw rewards. A more in depth blog on rewards is planned for the coming weeks.
2. Council functionality
Voting on Melon Council Members: We are currently working on establishing an appropriate structure to set up a Melon council elected by Melon token holders. The Melon council will represent the community in decisions regarding the future development of the Melon protocol as well as the allocation of funds reserved for supporting projects that form part of the Melon ecosystem:
A. Technical Functionality: After Melonport deploys v1.0 of the Melon protocol, the Melon council Members can vote to add and remove versions of the protocol.
Anyone can propose a new technical design to add or remove new versions of the protocol. Elected Melon council Members will decide on whether new versions are added or not. This may include decisions around deployment onto additional blockchains, i.e. the multichain solution.
Once a version of Melon is deployed (e.g. v1.2.3), every new fund that is created corresponds to that version until the next version is released (e.g v1.2.4).
Whenever a vault contract (we have previously referred to this as a core) is deployed along with its own set of modules, this is considered to be a fund. Vaults belonging to a removed version do not get deleted, rather they get decommissioned. Meaning they will be made unable to perform any managing (trading of assets) activity — rendering any investments in it virtually useless. Investors can at anytime redeem their funds even from a decommissioned vault.
B. Economic Functionality: Council members will have to vote on allocation of funds raised from contributions in the second token generation event. Thereby, the goal of the Melon council is to
- Preserve and grow the capital of these funds through diversification including a mandate to take stakes in Melon funds in the future.
- Award Developer Grants to module developers, financing research, highly desired modules and any necessarily deemed incentives by the council.
Many of you have asked for more guidance around inflation over the last months. We are still considering this as a way to further incentivise developers but believe that it does not need to be as high as originally intended. We can now firmly say that it will be no higher than 10% per annum and could be as low as zero.
Conflicts of Interest and How They Affect Our Design
Here we consider the conflicts between the four main groups of economic agents. There are two groups “Token holders” and “Ecosystem players” which consist of two sub-groups. We will assume for now that the conflicts within the sub-groups can be resolved and show this at the end.
We assume that all economic agents within the ecosystem will act as selfish agents trying to maximize their utility in their way of using the Melon protocol. This means agents are not viewed as being good (honest) or bad (corrupt); all parties are simply assumed to be rational, motivated by some utility function. However, it may not always be the case that rational behavior holds and there is no way to guarantee it. The only thing one can do, is try to design governance in a way that will best manage all economic agents.
When considering the types of conflicts below, we have also added a weighting number (score 1–3 — with 1 being a mild conflict which is easily resolvable with minimal economic consequences, 3 being serious conflict with big consequences and not easily resolved).
Investors vs Token holders/Managers/Suppliers
Managers vs Investors/Suppliers/Token holders
Suppliers vs Token holders/ Managers/Investors
Token holders vs Managers/Investors/Suppliers
Within suppliers, we noted earlier that there are two sub-groups: Module developers/ Module operators” . Before our analysis is complete, we should also consider the conflicts within these two sub-groups.
If we tally up the total number of attacks against each economic agent
From the above table, we conclude that fund “Investors” are the most vulnerable group with the most at stake. A possible solution is that the technical governance power could be split between token holders and investors in a pre-agreed proportion but this would be difficult to manage. However, we believe if the Melon protocol becomes successful — Investors themselves will be incentivised to acquire Melon tokens in order to have a say in the future design and usage functionality. Additionally, since Melon council Members are voted in by the Melon token Holders which can recall their election at any time — we believe there to be a strong alignment of interests between the Melon council Members and how the Melon protocol develops and protects its Investors.
In conclusion, the above should give an idea in the direction our development is headed towards. Of course, we are not able to set any of these decisions in stone. We will aim to be as consistent and coherent as we can, subject to feedback and new information garnered from the continual open-development process of Melon. Over the next weeks you will also hear a lot more from us in terms of development updates, and we hope to share with you our thinking process and challenges in order to keep our Melon community as up to date and knowledgeable as possible.
Subjects we plan to touch on in coming weeks include:
Please email us if there is a subject not listed below that you would like to hear more about.
Registering Modules via Satellite
We will soon be unveiling “Satellite” — a way to register and vote on the quality, security and importance of modules.
Rewards describe the way Managers get compensated for their efforts in managing a Melon fund.
A way to invest/redeem. This is a way to invest or redeem shares in a fund to gain exposure. Upon investment, new shares are created — on redemption, they are destroyed.
Measures put in place to limit Manager’s activities. A blog post will follow in coming weeks to outline Melonport’s initial risk management design.
A more detailed description of the Melon protocol governance, the Melon council Members and the Melon council Fund.
- Melon protocol is currently only on the testnet and open to anyone
- Once deployed to the mainnet, Managers using the Melon must act within the requirements of their local jurisdiction
Chairman & CTO at Melonport. Reto is a blockchain developer with background in mathematics from ETH Zurich. He started developing Ethereum smart contracts immediately after their launch in 2015. He worked as a smart-contract developer at Brainbot Technologies (which is building the high-speed Raiden Network) and is host of Zurich’s Blockchain Hacklab. Before this Reto developed a profitable trading algorithm for sport betting exchanges in C++.
*** Please note some changes and updates have been made to this blog since original publication
Mona El Isa
CEO & Founder. Mona is a former star-trader at Goldman Sachs, promoted to Vice President by the age of 26 and made the “top 30 under 30” list in Trader Magazine in 2008 and Forbes Magazine in 2011 after profitably trading the 2008 and 2011 crashes. Moved to Geneva-based macro fund Jabre Capital in 2011, before deciding in 2014 that the future of finance lay in blockchain technology. She studied Economics & Statistics at the University College London.