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 [1]. 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.

Helping Melon grow wings to fly …

Mission statement

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 [2]
• Nurturing innovation in the asset management industry

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, 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 [4] 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.

From token holder governance to a skill-based governance model

As rightfully pointed out by Tony Sheng in Not all governance is voting (highly recommended reading!), governance is not a matter of naively adding a voting feature: “A project can have strong governance without voting and a project with voting can have terrible governance”.

Initially, our thinking on governance leaned towards token holder-based governance, where token holders vote on decisions related to the Melon protocol. As governance research progressed, we realized that token holder governance was the easy way out, and was by no means suited to our use case. In fact, it was possibly the least well-suited solution, and could lead to dangerous and irreversible outcomes for the Melon protocol and the ecosystem as a whole.

The ideal governance model is one that protects both asset managers and investors, as well as providing them with stability, integrity and security.

We believe that a token holder governance model is not suited to our use case, and we explain why below.

It is expected that, in the future, large asset managers will operate on top of Melon. Those asset managers have access to large pools of financial resources, and are very often in adversarial positions being competitors. Given the relatively low market capitalization of Melon, it is quite affordable for a bad actor to build up a position in MLN in order to massively influence future votes on code changes, resource allocation, network parameters, or other critical aspects of the system. If a single actor can take over control of a supposedly decentralized protocol by simply buying up tokens, then you don’t have a decentralized governance model, you have a protocol up for sale.

It is a common mistake to confuse decentralization with token holder voting. If the token distribution is (or could easily become) highly concentrated, token holder voting always results in a plutocratic system [5], rather than a decentralized one. It appears that decentralization is not necessarily best achieved through token holder governance. Decentralization is often poorly defined, so we should clarify what we are trying to accomplish with it. In the case of Melon, we aim at providing users (fund managers and investors) with reliable, permissionless and open-source software, or an infrastructure that they can safely build and grow their business upon. Melon should stand as a robust and censorship-resistant alternative to traditional asset management.

Let’s take a simple example. Imagine you are the second biggest fund manager (#2) on Melon; the last thing you want is your biggest competitor (#1) build up a large position in MLN and take over decision power on Melon. If fund manager #1 managed to acquire a majority voting block, she could use her voting power to influence any protocol-related decision, with the sole intent to harm the business of fund manager #2, therefore competing with an unfair advantage. No serious fund manager would accept such an important business risk, nor should they.

A well known pitfall of centralized platforms is the presence of powerful central entities that can use their monopolistic/oligopolistic positions to change the rules for incumbents, therefore creating lots of uncertainty for innovators and entrepreneurs [6]. Thus, one added value of decentralized over centralized systems is that they offer infrastructure to startups, entrepreneurs and other groups to build their businesses without worrying about a centralized entity changing the rules on them when they become a threat or serious competition. This is where we see the true value of a decentralized system. Therefore, our governance model must preserve that property. Token holder governance in the asset management industry does not prevent powerful actors from leveraging their position at the expense of the rest of the users, falling back precisely to the problem of centralized platforms which we are trying to escape.

With on-chain voting also comes vote buying. As elegantly explained by Philip Daian [7], if smart contracts can be used for on-chain voting, they can also be used to buy votes, or bribe voters. Given the empirical voter apathy observed [8], small token holders with low engagement have a high incentive to take the payoff, rather than abstain. Furthermore, Philip Daian also highlights the possible formation of decentralized cartels using trusted hardware. On-chain voting is vulnerable to several attack vectors as long as users are able to generate their own keys (even with an identity system in place).

Furthermore, it is our claim that even if we could ensure an equitable distribution of tokens among a group of interested peers, token holder voting is still not an adequate model for the development of a technical protocol. We submit that decisions made among individuals without domain expertise leads to suboptimal outcomes. One reason is that, in giving voters the ability to alter course, the direction of the project may become more capricious than it would under the guidance of a group bound by fiduciary duty (duty of care, loyalty and impartiality towards the users: asset managers and their investors). Another reason is that the decision making process itself becomes sluggish, given the time and effort it takes to conduct a vote with a large enough turnout to be considered legitimate.

Finally, token holders have a set of interests that may or may not overlap with what is best for the project’s longevity and growth. We may even find that token holders and users have diverging sets of interests. For example, token holders have a clear short-term interest in raising the amgu price (read more about this in Melonomics 2) if network effects are high, since this would result in an increase of the amount of MLN tokens burnt. This is fundamentally opposed to the interest of the users, who could overnight become subject to dramatically high fees, potentially jeopardizing their businesses. On the other hand, we believe token holders also have an interest to protect long term viability of the network (ie. setting sensible fee level). However, building a sustainable model based on (unidentified) token holders’ long-term rationality would be irresponsible, as incentives for each token holder differ.

In contrast, we assert that those best suited to govern the direction of the protocol are those closest to its development and those most impacted by it. A technical protocol needs technical decision makers, and this group should be bound to do what is best for the project to thrive. This is not to say that the protocol or its development become a black box, since it is released under an open source license and developed in the public space. It is simply a transparent way to guard against decisions that may be fickle, inefficient or maligned for any of the listed reasons. Since users (asset managers and their investors) are the one mostly affected by the protocol development, the ideal model should also provide strong protection and representation for this group.

This analysis provides the ground for the user centric and skill-based governance model we would like to experiment with for the first years of Melon.

Melon Governance System 1.0

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

As illustrated above, 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 [9]

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 [10]) 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 [11]:

• 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)

Fiduciary duties

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 20% 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.

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

Resource allocation

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.

2. Developers

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 mtc@melonport.com.

3. Users

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.

I know what you’re all thinking: how does this model align with the token holders interests?

The very interests of the token holders are deemed to be taken care of by Melonomics 2. Melonomics 2 provides a framework and mechanisms whereby the token value is aligned with the usage of the network. If you haven’t had the chance to read on Melonomics 2, you can have a read here. As shown in this blog post, the interests of the token holders lie in the user growth. It is therefore essential to provide a model that protects the users and caters to their needs. By forming a council of skilled and competent individuals, we strive towards high software security and quality standards. By adding MEB representatives on that same council, we make sure that users will have an efficient way to communicate their needs.

We also provide an additional alignment between the token holders and the MTC through the incentivization model of its members. MTC members are rewarded with a percentage of the annual MLN inflation pool; those tokens are vested over long period of time, which incentivizes MTC members to take decisions that favor the growth of the network usage, and ultimately of its market cap. Since MTC members are rewarded with vested MLN tokens, they become long term token holders themselves and are more likely to adopt the right behavior.

Ultimately, token holders also have standard recourse if they disagree with the decisions taken. The first and easiest one is to express themselves through the market, by selling the tokens. The second one is the ever present option to fork the token and its network -this requires slightly more efforts but is always possible.

“Governance is not a feature, it is a complex system”, Tony Sheng [12].

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.

As for us, we look forward to watching decentralized governance model experiments unfold in the space. This is an extremely exciting field, which has the potential to drastically transform organizations and allow community-owned networks to support innovation in powerful ways.

However, there is a common stakeholder to consider to all of the different projects’ governance model, and that is the crypto industry as a whole. Indeed, the governance experiments we conduct will ultimately reflect on the reputation of our industry as a whole. We must keep that in mind when thinking about and deploying novel governance systems.

As highlighted by Vlad Zamfir, “The global nature of the technology is actually a huge global governance opportunity that we really shouldn’t miss” [13].

This piece was co-authored by Mona El Isa and Jenna Zenk

We invite you to provide constructive feedback and comments. Please especially reach out to us if you think we’ve made a mistake in our thinking or simply want to provide feedback. This model is subject to further research and therefore will most likely evolve over time.

A special thanks to Matthew Di Ferrante (ZK Labs), Dean Eigenmann (ENS and ZK Labs), Alex Lindgren (LloyLaw), Dylan Grice, Janos Berghorn (KR1), George Hallam, Keith Taylor, the Melon team, Vlad Zamfir (Ethereum Foundation), Will Harborne (Ethfinex), Brendan Dillon (Consensus Clubs), Eelco Fiole, Konstantin Lomashuk (Cyberfund), Nick Munoz-McDonald (Solified.io), William Peets (Passport Capital), Ella Papanek (Passport Capital) & Jon Kol (Passport Capital) for their feedback and discussions on this topic. Any remaining mistakes are our own.

Footnotes sweetness ❤

[1] Read more on what is Melon: https://medium.com/melonport-blog/what-is-melon-2018-edition-3437f3d064d8

[2] https://www.pwc.com/gx/en/asset-management/asset-management-insights/assets/awm-revolution-full-report-final.pdf

[3] Blockchain governance 101, Vlad Zamfir, https://blog.goodaudience.com/blockchain-governance-101-eea5201d7992

[4] In this context we mean the creation of new MLN token by a pre-defined algorithm. More information about the inflation curve will be published in a future blog-post.

[5] Governance Part 2 : Plutocracy is still bad, Vitalik Buterin, https://vitalik.ca/general/2018/03/28/plutocracy.html

[6] This is well explained in Chris Dixon’s following post: https://medium.com/@cdixon/why-decentralization-matters-5e3f79f7638e

[7] On-chain vote buying and the rise of dark DAOs, Philip Daian, http://hackingdistributed.com/2018/07/02/on-chain-vote-buying/

[8] Example: low turnout during the carbon vote during the DAO hack, despite serious and severe implications

[9] Against community governance, Dean Eigenmann, https://medium.com/@decanus/against-community-governance-326dc82b27d3

[10] Against community governance, Dean Eigenmann, https://medium.com/@decanus/against-community-governance-326dc82b27d3

[11] Subject to further changes/additions

[12] Not all governance is voting, Tony Sheng, https://www.tonysheng.com/voting-governance

[13] My intentions for blockchain governance, Vlad Zamfir, https://medium.com/@Vlad_Zamfir/my-intentions-for-blockchain-governance-801d19d378e5

Recommended readings (if you want more, just reach out)

• Why decentralization matters, Chris Dixon: https://medium.com/@cdixon/why-decentralization-matters-5e3f79f7638e
• Blockchain governance 101, Vlad Zamfir: https://blog.goodaudience.com/blockchain-governance-101-eea5201d7992
• Not all governance is voting, Tony Sheng: https://www.tonysheng.com/voting-governance
• Governance Part 2 : Plutocracy is still bad, Vitalik Buterin: https://vitalik.ca/general/2018/03/28/plutocracy.html
• On-chain vote buying and the rise of dark DAOs, Philip Daian: http://hackingdistributed.com/2018/07/02/on-chain-vote-buying/
• Against community governance, Dean Eigenmann: https://medium.com/@decanus/against-community-governance-326dc82b27d3
• My intentions for blockchain governance, Vlad Zamfir, https://medium.com/@Vlad_Zamfir/my-intentions-for-blockchain-governance-801d19d378e5