Governing Preferences

TL,DR:

• The R&D team has been looking into governance models.
• On-chain voting has many problems, some are the high costs (especially at times gas is high), voter apathy, users not keeping up with the platforms, etc.
• An approach to increase user participation in governance is the one the team has called “governing preferences”
• In short, users pre-set their preferences ahead of time, and those preferences will “automatically” be used to determine a vote.
• There are a few challenges and considerations, however, we hope this approach is picked up by those needing solutions for the challenges mentioned and expanded further.

Blockchain projects generally use on-chain voting as a community-driven governance mechanism. As in any kind of voting event, sometimes they suffer from low voter turnout. In some cases, voting can be replaced with what we call Governing Preferences.

At Golem we also research and discuss governance and adjacent topics. As part of these processes, we have come up with several ideas, and today we’re sharing one.

Let's consider governance for setting a system parameter, more specifically, a number parameter such as the stability fee in MakerDAO. Typically the process begins when an eligible person proposes a new value for the parameter, possibly after an open forum discussion. The voting is then set on-chain with a schedule, it takes place, and then after the end date voting results are applied.

With the Governing Preferences model, community members do not need to vote. Instead, they individually set their preference for the parameter value on-chain. The global system parameter value is the median of all individual preferences set by the members.

There is a significant difference between voting and Governing Preferences. Voting ends with a decision applied to the system at a given point in time. Individual preferences are long lasting and can be changed anytime by members. They do not need to vote in order to change their preferences. A member can set it once and keep it but also can change it every day. At any point in time, the valid global system parameter value should be calculated as the median value of all preferences. You do not need to vote to change it, just recalculate it. So this is a more continuous approach than period based votings. For that reason it is preferred to use term members instead of voters.

Governing Preferences can be applied to set a fee, collateralization ratio or interest rates for instance. Members can set their private fee values, but the median of these values is the global fee value. A completely different example is an opinion, let’s use an opinion towards a particular venue as an example. Everyone can have their own opinion, around how much they like this venue. But the general opinion is some kind of an average of these individual opinions. The general opinion towards the venue changes when individual opinions change.

Governing Preferences is not good for everything. A decision to implement a new functionality or not requires voting. The same refers to funding projects and giving grants. So it is not good for one time decisions but it is good for adjusting quantitative value.

Note that in this case, a median value works better than an arithmetic average. Simply, malicious members can set excessive-high preferences in order to break the governance mechanism.

Replacing voting with continuous preferences has some implications in governance mechanics:

1. Once a token holder sets the preference, its voice is valid, even if it remains passive afterward. Participation is much higher, but passive members can affect an outcome.
2. With voting you can think like ‘let others vote, the system will survive’. With Governing Preferences, you do not have to do anything. But if you clearly disagree with the system parameter value, you think ‘something has to be done’ and feel the pressure. Somehow you feel responsible for the system.
3. When maintainers want to change the system parameter value, they have to convince the (weighted) majority of token holders with preferences, even those that are passive.

In theory, Governing Preferences are simple and effective but there are more or less technical considerations. Let’s look closer at some of them.

Calculating the median is costly in terms of Ethereum gas cost. But it is less painful to check whether a given value is the median. An optimistic approach can help. The responsible person can set a new parameter value and a smart contract checks whether it is the median or not. This needs further considerations, like how to force the responsible person to act.

It is clear that preferences can be weighted, with the number of held tokens. Although weights may change frequently because of trading, this can result in volatility of the system parameter value, staking can be used as a countermeasure. However, the question of how to balance alternative cost is token-specific.

In addition, this solution can still suffer from high volatility because any individual preference change can alter the system parameter value. One of the interesting approaches to overcome the fluctuations is to set a stable interval. The median is a value in the middle:

Say that ⅓ median is a value in ⅓ and the same way ⅔ median. So the system parameter value is recalculated when it is lower than ⅓ median of all preferences or greater than ⅔ median of all preferences. Note that the system parameter is changed when at least ⅙ of all members change their preferences.

There are more considerations to be made, but our first goal was to present this idea in order to gauge opinions and interest. The solution is not implemented yet, and we are not sure it will be, but we consider it interesting and helpful enough to share - in hopes it can be useful for more people as well.