Read the full post here: https://medium.com/melonport-blog/introduction-to-the-melon-governance-system-f6ff73c70eb0
Introduction to the Melon Governance System
Melon ([méllōn], μέλλωv; Greek for “future”) is an open-source protocol for on-chain asset management. It is a blockchain software system that seeks to enable participants to set up, manage and invest in technology regulated and operated funds in a way that reduces barriers to entry, whilst minimizing the requirements for trust . The Melon protocol is a set of rules implementing the behavior of an investment fund as a system of smart contracts. These rules are also meant to protect the investor and fund manager from malevolent behavior of each other, even when both parties remain private.
The Melon protocol has been developed by Melonport AG. In February 2019, Melonport AG is expected to deliver v1.0 of the Melon protocol to the community, before winding down the company. This post addresses the question of future developments, maintenance and decisions relating to the Melon protocol once Melonport AG steps down as sole developer and maintainer.
The Melon protocol enables a new class of investment funds, referred to as Technology Regulated and Operated Funds (TROF). A TROF constitutes a first-of-its-kind on-chain and decentralized investment vehicle, made possible through leveraging decentralized technologies. Melon enables participants to perform the operational, compliance and administrative parts of asset management at a fraction of the cost, with higher transparency, security, and minimal trust requirements.
Beyond the software, Melon aims to provide an infrastructure for the asset management of the future, “μέλλωv” (Greek for “future”). The large variety of applications (eg. VC, pension funds, insurance, hedge funds, etc) in on-chain asset management need a solid infrastructure to build upon, and Melon can be seen as such; it is the backbone of the on-chain asset management, or asset management 3.0.
Melon is pioneering the way for open-source on-chain finance and, as such, is not intended to be owned by a single entity. Rather, it should be seen as an open-source public good. Melon was built in a way that is permissionless, inclusive, reliable and transparent. Users are defined as both asset managers and investors interacting with funds operating on the Melon protocol. Users do not need permission to interact with Melon.
The main goals of Melon can be summarized as:
- Providing a robust infrastructure for on-chain asset management
- Providing a reliable, secure and transparent tool for managing investment funds on-chain
- Lowering barriers to entry to what is forecast to be an $84.9 trillion asset management industry by 2025 
- Nurturing innovation in the asset management industry
“It’s about the processes that participants in governance use to make decisions. It’s also about how they coordinate around decisions and decision-making processes. It includes the establishment, maintenance, and revocation of the legitimacy of decisions, decision making processes, norms, and other mechanisms for coordination” , Vlad Zamfir. 
As part of the open-source finance stack, Melon is not owned by Melonport AG. In February 2019, Melonport AG will deploy v1.0 of the Melon protocol. Upon deployment, Melonport AG will no longer remain sole maintainer/developer of Melon. Therefore, as part of releasing the project in the hands of the community, Melonport AG aims at proposing a governance structure and decision-making processes that will underpin the Melon ecosystem and shall drive future development, acceptance and adoption of the Melon protocol.
To that point, it is pertinent to address the following:
- What it the scope of the decision-making processes (what)
- Principles, values and goals that shall underpin any future decision (why)
- Decision-making processes and roles (how)
What future matters require decision-making capabilities?
This section aims to address the what.
(i) Protocol upgrades
Future improvements to the Melon protocol smart contracts including bug fixes, security patches, feature additions, and third-party integrations. This also includes adding new assets to the Melon Asset Universe, as well as authorizing new exchanges to interact with the Melon protocol.
Generally, protocol upgrades refer to changes in the Melon smart contracts codebase.
(ii) Resource allocation
Inflation  is the only financial resource available to the Melon community and a critical source for future growth and network effects. The yearly inflation of MLN is intended to be used to fund future developments of the Melon protocol, as well as projects building in the Melon ecosystem.
Decisions need to be made as to:
The definition of priorities regarding changes or additions to the protocol Choosing adequate developers to conduct specific research or implementation Reviewing and assessing asset management projects applying for funding
(iii) Network parameters
The asset management gas price per amgu (asset management gas unit) needs to be set and adjusted according to network usage and market conditions. For more context on this, please refer to Melonomics 2.
Which long term goals and principles should underpin Melon related decisions?
This section aims at addressing the why.
Melon is intended to be a robust, secure and censorship resistant asset management infrastructure.
The system aims at being drastically more efficient than any other existing solution. Melon is competitive to existing asset management alternatives and needs to remain competitive in the future. Melon constitutes an opt-in alternative to the current asset management industry.
Melon is inclusive and permissionless. It should be easily accessible without restriction, to anyone on earth, no matter where they are.
Lowering barriers to entry. Melon should always strive to lower barriers to entry for asset managers. It also gives investors access to a deeper and more accessible talent pool.
Putting users first. It should be clear that the goal is to provide a best-in-class tool to asset managers around the world. Melon aims to stay ahead of the curve and provide advanced and sophisticated infrastructure to all kinds of asset managers.
Any decisions taken in the future should be in line with the following long term goals:
1 Preserving the integrity of the network
2 Maximizing user adoption
3 Fostering innovation and increasing network attractiveness
Ultimately, those three goals should have a long-term positive effect on the value of the MLN token.
Melon Governance System 1.0
This section aims at addressing the how and presenting our current thinking for the Melon Governance System.
When defining this governance model, our unique goal has been to think about what is best for the Melon protocol’s longevity, integrity and success, whilst keeping in mind the experimental aspect of this type of organization.
“Governance is hard, especially for decentralized protocols. Allowing a community to govern a protocol does not make it any easier”, Dean Eigenmann 
The initial Melon governance system is very user-centric, and ensures the maintenance and development are driven by technically informed parties.
1. Melon Technical Council (MTC) and Melon Council (MC)
We therefore propose a technical council (see also technocratic council ) composed of a diverse set of known and identified entities or persons solely responsible for the following:
Deployment of protocol upgrades (including code upgrades, feature additions and bug fixes)
Management of the set of ENS subdomains pointing to the Melon smart contracts
Allocation of resources to developers and application developers.
Adjusting network parameters such as the cost per amgu (or Melon gas price)
The formation of a council aims at providing more efficiency in the decision-making system (in comparison to a token holder governance model), but also at aligning the decision-makers with the best interests of the Melon protocol and its surrounding ecosystem (through fiduciary duties towards users). It minimizes the number of decision makers and ensures those decision-makers are accordingly qualified.
The Melon Council (MC) is comprised of the MTC (Melon Technical Council) members and of the MEB (Melon Exposed Businesses) representatives.
Formation of the Melon Technical Council
There were a number of considerations to make when deciding on the makeup of this body. We evaluated the possibility of having token holders elect the council, but concluded that this is still susceptible to the eventual plutocracy outlined above. Instead, we aim at promoting a skill-based, meritocratic system.
The Melon Technical Council (MTC) will initially be appointed by the Melonport AG team, prior to the main net v1.0 deployment of Melon in February 2019. That means that Melonport AG will initially allocate an odd number of seats on the MTC, and ensure that those seats are occupied by diverse actors, with the right set of skills, expertise and incentives.
Subsequent to that, the MTC will grow organically by holding a Melon Council two-thirds vote on incoming applications. Incoming applications shall be reviewed by the existing members and approval or rejection shall be communicated with the according rationale.
The MTC is a subset of the Melon Council (MC). MTC members will be joined by MEB members (see MEB section below and MC statutes) to form the Melon Council. It is expected that the Melon Council will evolve in a consortium-like fashion of technically skilled and business exposed parties.
Melon Technical Council inclusions/exclusions
Applicants to the Technical Council shall meet the following criteria :
Provable technical skills and expertise with regards to Melon (its codebase, token economics, ecosystem) and/or existing meaningful contribution to the Melon codebase A declared absence of any conflict of interest with the Melon vision and ecosystem Willingness and ability to dedicate time and resources to the Technical Council activities High evidenced ethical standards, good reputation and compliance with the MC statutes Willingness to reveal their identity The decision-making processes shall be open and transparent to the community. The Melon Council will be responsible for providing context to their decisions to the community. The Melon Council may or may not decide to consult the token holders sentiments on a specific topic.
Melon Council members can be excluded through a ⅔ majority vote of the MEB (see MEB section and MC statutes)
The Melon Council will be bound by fiduciary duties, guiding principles and MC statutes. This means the MC members will be obligated to act in the best interest of the Melon protocol. Any member violating their fiduciary duties will expose themselves to the revocation of their seat.
If a MC member has a conflict of interest on a specific question, they should inform the rest of the members immediately and abstain from voting on the matter in question.
MTC Incentivization model
The people with the right skills for the MTC are scarce so we need to provide the right incentives structure for the MTC members. We therefore propose to ring-fence x% of the MLN annual inflation pool to reward the MTC members. The MLN tokens received by MTC members will be vested.
Initially this should just cover their costs, but by providing that reward as a percentage of the annual inflation (ie. a proportion of total market cap), we also introduce an incentive to grow the market cap of Melon through adding value to the network.
This has a size self-balancing side effect: as the pools of incentives grows, the MTC can grow. If the pool of incentives decreases (ie. market cap decreases), it is likely that some members of the MTC will resign or be forced out as it will no longer be worth their time and effort. This will in turn grow the asset pool for the remaining members. At the same time, if the number of MTC members becomes too small and the pool of available assets grows, more members will be attracted in.
Note here that only MTC (not MEB representatives) members are eligible for this pool of reward.
When a protocol upgrade is needed (feature addition, bug fixes or security vulnerability), the MTC can either implement the upgrade itself or mandate an external developer or entity to conduct the implementation.
Once the implementation is finished, the new code must be audited by an independent party. If the audit passes and the majority of the MTC agrees, the new contracts can be deployed.
The MTC owns the key of the owner address of the Melon ENS subdomains. The sole power of the MTC lies in their ability to change the ENS subdomain pointers of the Melon smart contracts to the newly deployed contracts. Note here that only the MTC (and not the whole MC!) approval is needed to update the ENS subdomain pointers.
The MTC does not have the power to force an upgrade on the user or to shut down a previous version. The responsibility to run secure and up-to-date code relies solely on the user.
The Melon protocol aims at providing the right set of incentives to the people maintaining it and developing it. The inflation (whose curve has yet to be defined) will be used solely for this purpose.
The MTC will receive compensation from the inflation pool to cover costs associated with their duties as MTC members (as per MTC incentivization model above). Based on the defined roadmap and scheduled improvements, the Melon Council will compensate developers and contributors to the Melon protocol. The MC can either post bounties for specific desired features with the associated reward, or accept proposed MIPs by external developers. Projects in the asset management 3.0 industry can also apply for funding from the inflation pool (see Melonomics 1). The MC will then conduct a thorough review on funding requests. Approval of a project requires a 50% majority + 1 vote. The MC should only accept funding requests for projects that are expected to add a net value to the Melon ecosystem as a whole. Network parameters
The Melon Engine mechanisms were recently presented in Melonomics 2. The MC will be provided with clear guidelines by the Melonport AG team with regards to adjustment of the amgu price (or Melon gas price). It will also be provided with the right tooling and framework to help make informed decisions.
It is hard to predict today how often this variable will need to be adjusted, but we see two main factors that will drive this change:
Burn rate, directly linked to usage levels of the network; as usage of the network goes up, the Melon gas price should go down to maintain a balanced and healthy burn rate. Market conditions on the MLN/ETH and ETH/USD pair More details on this part will be provided in a future blog post.
Rotating leads and responsibilities
We believe a group of people are more efficient when each person is held responsible and accountable.
The MC should elect a Chair and a Vice-Chair at the beginning of each year. The Chair and Vice-Chair will be responsible for the coordination of the MC, its meetings and preparing the agendas.
For the sake of efficiency (and to deter free-rider behavior), we propose a rotating lead system where every year, members can take a leadership role on specific topics such as: audits, features, ecosystem projects, network parameters etc. These may rotate every 6 months if necessary.
The establishment of a technical council should not be seen as limiting contributions to the development of Melon to the members of the technical council. Participation in development is not limited to the MTC and should always be open to the public.
The Melon protocol is entirely open-source, released under the GPL-3.0 license and, as such, any developer is invited to work on feature additions, third-party integrations, bug fixes and submit pull requests. Pull requests will be reviewed by the MTC. However, if a specific pull request is not merged by the MTC, that is not to say it can not be adopted by users.
Developers can apply for funding by submitting proposals to the MC, under the form of Melon Improvement Proposals (MIP).
Developers can also decide to implement a specific feature or improvement for which the MC shows strong interest. In that case the developer will receive the funding corresponding to the task at hand.
Last but not least, developers having already contributed to the codebase, and willing to increase their engagement with Melon should strongly consider applying for a seat at the Melon Technical Council. If you are interested and meet the MTC requirements, reach out to firstname.lastname@example.org.
To be clear, the proposed Melon governance model is a user-centric model. It ensures users have permissionless access to a secure asset management protocol, and are protected from malevolent actors in the network. At the same time, users have the option to benefit from continuous innovation and improvements on top of the protocol, safeguarded by the thorough checks and analysis of the Melon Council bound by fiduciary duties. Indeed, the Melon Council is responsible for taking decisions preserving the interest of the users of the network.
The users always remain in full control, and is the sole decision maker with regards to the software they are running.
Neither the MC nor the token holders can impact the smart contract code used by a fund manager. The fund manager must take a voluntary action in order to upgrade to new versions of the code, and the fund’s investors are free to instantly redeem their shares if they are not happy with the version of the code being used. The fund manager is never forced to use a new version of the code they may or may not feel comfortable with. Users take full responsibility to upgrade from code that may contain security vulnerabilities.
As a result, the convergence of users towards a specific version of the Melon protocol shall give a strong indication to the MC of their alignment with the users’ sentiments and needs. Although the MTC owns and controls the ENS subdomains pointing to the latest contracts, the users are the ones truly deciding which version to base their business upon, which constitutes a strong signal to the community. This is further enabled by the unstoppable character of smart contracts (once deployed, the Melon contracts can not be taken back by the deployer).
However, users will be highly encouraged to always use the latest versions of the Melon protocol, as security vulnerabilities can be discovered and will be fixed in protocol upgrades. Users are also encouraged to conduct their own analysis, audit and review of the contracts they intend to use. The ultimate choice and responsibility relies solely on the user.
4. Melon Exposed Businesses (MEB)
In order to guarantee that the voice of the users are heard and considered, it was deemed sensible to encourage the formation of the Melon Exposed Businesses.
The intent is to unify the voices of users whose businesses heavily rely on Melon and its future development. This includes fund managers with a minimum threshold of assets managed on Melon (to be defined), or applications and projects utilising the Melon protocol.
We aim for the MTC and MEB to maintain a close relationship and preserve a healthy feedback loop. The MTC will be required to address the concerns raised by the MEB, and both entities should work together at defining the pressing needs of the users of the network.
Another important function of the MEB is to balance power by checking the decisions made by the MTC, and informing users about potential suspicious activity. The MEB will be able to elect its delegates to represent their interest on the Melon Council (see MC statutes). It is also possible for the MEB to vote on the exclusion of a Melon Council member violating the MC statutes (through a two-third majority vote).
In the future, as more businesses build on Melon, it is expected that the MEB will grow in size. The Multichain Asset Managers Association (MAMA) as a trade body may be able to facilitate the organization of such a body.
Rather than a static model, governance is a dynamic and complex process. The above model is a reflection of our current thinking, and it is what we would like to start with for the first few years, but it is expected to change and evolve over time. The Melon Council should also stay aware of the future developments in decentralized governance, as they might decide at some point in the future to migrate towards a new model.