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.

Assumptions Made:

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.

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.

: 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