Read the full post here:

Introduction to the watermelon Governance System

watermelon ([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 [1]. The watermelon 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 watermelon protocol has been developed by Melonport AG. In February 2019, Melonport AG is expected to deliver v1.0 of the watermelon protocol to the community, before winding down the company. This post addresses the question of future developments, maintenance and decisions relating to the watermelon protocol once Melonport AG steps down as sole developer and maintainer.

Mission statement

The watermelon 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. watermelon 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, watermelon 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 watermelon can be seen as such; it is the backbone of the on-chain asset management, or asset management 3.0.

watermelon 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. watermelon 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 watermelon protocol. Users do not need permission to interact with Melon.

The main goals of watermelon can be summarized as:

Governance purposes

“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. [3]

As part of the open-source finance stack, watermelon is not owned by Melonport AG. In February 2019, Melonport AG will deploy v1.0 of the watermelon 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 watermelon ecosystem and shall drive future development, acceptance and adoption of the watermelon protocol.

To that point, it is pertinent to address the following:

What future matters require decision-making capabilities?

This section aims to address the what.

(i) Protocol upgrades

Future improvements to the watermelon protocol smart contracts including bug fixes, security patches, feature additions, and third-party integrations. This also includes adding new assets to the watermelon Asset Universe, as well as authorizing new exchanges to interact with the watermelon protocol.

Generally, protocol upgrades refer to changes in the watermelon smart contracts codebase.

(ii) Resource allocation

Inflation [4] is the only financial resource available to the watermelon 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 watermelon protocol, as well as projects building in the watermelon 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.

This section aims at addressing the why.

watermelon 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. watermelon is competitive to existing asset management alternatives and needs to remain competitive in the future. watermelon constitutes an opt-in alternative to the current asset management industry.

watermelon is inclusive and permissionless. It should be easily accessible without restriction, to anyone on earth, no matter where they are.

Lowering barriers to entry. watermelon 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. watermelon 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:

Ultimately, those three goals should have a long-term positive effect on the value of the MLN token.

watermelon Governance System 1.0

This section aims at addressing the how and presenting our current thinking for the watermelon Governance System.

When defining this governance model, our unique goal has been to think about what is best for the watermelon 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 [9]

The initial watermelon governance system is very user-centric, and ensures the maintenance and development are driven by technically informed parties.

1. watermelon Technical Council (MTC) and watermelon Council (MC)

We therefore propose a technical council (see also technocratic council [10]) composed of a diverse set of known and identified entities or persons solely responsible for the following:

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 watermelon 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 watermelon Council (MC) is comprised of the MTC (watermelon Technical Council) members and of the MEB (watermelon Exposed Businesses) representatives.

Formation of the watermelon 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 watermelon Technical Council (MTC) will initially be appointed by the Melonport AG team, prior to the main net v1.0 deployment of watermelon 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 watermelon 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 watermelon Council (MC). MTC members will be joined by MEB members (see MEB section below and MC statutes) to form the watermelon Council. It is expected that the watermelon Council will evolve in a consortium-like fashion of technically skilled and business exposed parties.

watermelon Technical Council inclusions/exclusions

Applicants to the Technical Council shall meet the following criteria [11]:

Provable technical skills and expertise with regards to watermelon (its codebase, token economics, ecosystem) and/or existing meaningful contribution to the watermelon codebase A declared absence of any conflict of interest with the watermelon 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 watermelon Council will be responsible for providing context to their decisions to the community. The watermelon Council may or may not decide to consult the token holders sentiments on a specific topic.

watermelon Council members can be excluded through a ⅔ majority vote of the MEB (see MEB section and MC statutes)

Fiduciary duties

The watermelon 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 watermelon 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 watermelon 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.

Protocol upgrades

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 watermelon ENS subdomains. The sole power of the MTC lies in their ability to change the ENS subdomain pointers of the watermelon 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.

Resource allocation

The watermelon 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 watermelon Council will compensate developers and contributors to the watermelon 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 watermelon ecosystem as a whole. Network parameters

The watermelon 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 watermelon 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 watermelon 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.

2. Developers

The establishment of a technical council should not be seen as limiting contributions to the development of watermelon 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 watermelon 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 watermelon 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 watermelon should strongly consider applying for a seat at the watermelon Technical Council. If you are interested and meet the MTC requirements, reach out to

3. Users

To be clear, the proposed watermelon 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 watermelon Council bound by fiduciary duties. Indeed, the watermelon 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 watermelon 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 watermelon contracts can not be taken back by the deployer).

However, users will be highly encouraged to always use the latest versions of the watermelon 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. watermelon 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 watermelon Exposed Businesses.

The intent is to unify the voices of users whose businesses heavily rely on watermelon and its future development. This includes fund managers with a minimum threshold of assets managed on watermelon (to be defined), or applications and projects utilising the watermelon 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 watermelon Council (see MC statutes). It is also possible for the MEB to vote on the exclusion of a watermelon 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 watermelon 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.