DFINITY Foundation

Internet Computer Association

Present design proposal for Open Governance canister

## Objective

Service nervous systems (SNSs) are algorithmic DAOs that allow developers to create decentralized, token-based governance systems for their dapps. 

After the community adopted the R&D motion proposal stating that the foundation should work on this topic, this present motion proposal suggests a concrete design for an open governance canister implementation that can then be used to realise the SNSs. 

The proposed governance canister design is similar to the  governance canister of the Network Nervous System (NNS) but simpler and more flexible, allowing each SNS community to choose the configurations according to their needs. This design is also presented and discussed in this forum: https://forum.dfinity.org/t/open-governance-canister-for-sns-design-proposal/10224 .

## Background

### Relation to the original SNS design & overall approach
DFINITY Foundation presented a first proposed [SNS design](https://www.youtube.com/watch?v=L4443aaAP5A) in October 2021. The community feedback was that the SNS design was rather complex and does not leave a lot of freedom to developers to configure a DAO to their needs. Some developers mentioned that they have a particular DAO or use case in mind and are only interested in an implementation of a ledger or governance canister, which they plan to integrate with existing canisters. 

The goal of SNSs is also to eventually provide open governance solutions *on the press of a button* for those who are not experienced developers themselves. This motivates that a concrete implementation and usable interfaces to deploy and upgrade SNSs are provided to the community.

To address all of these concerns, DFINITY Foundation proposes the following new approach:
1. Release the different building blocks in multiple stages, such that the community can make use of intermediate deliverables (e.g., single canisters) as soon as they are ready
2. Evolve these single building blocks to arrive at a concrete implementation that can be used without engineering efforts
3. Make the concrete implementation modular and the single components configurable so that each SNS can be configured as suitable for the dapp that it governs

### Context with other SNS projects 
More concretely, We (the DFINITY Foundation) proposes the following initial stages:

1. Improve the NNS ledger canister so that it can also be used for other tokens
2. **Implement a governance canister (the design presented and discussed in this proposal)**
3. Tooling and support for the deployment and upgrade of SNSs that consist of multiple canisters, including the ledger and governance canister from above (design will be presented in a separate forum thread in the coming weeks)
4. More steps towards allowing SNSs on the press of a button, including frontend support, support for initial token distribution etc. (less concrete, this depends on the previous steps and the feedback there)
 

## Proposed design for the open governance canister

### Summary design
On a high level, the idea is to reuse only those concepts of the NNS that are relevant. 
This would allow us to reuse some code from the NNS governance canister but simplify the design by omitting concepts that are only relevant in the context of the NNS.

More concretely, DFINITY Foundation proposes to reuse the concepts of 
* *neurons*, which facilitate stake-based voting that guarantees that voters are invested in the respective governance token and therefore incentivized to vote in the best interest of the system.
* *proposals* as the SNS should allow users to make suggestions, e.g., how to evolve the associated dapp, and for others to vote on these decisions.

As with the NNS governance, it is expected that the governance canister is deployed with an associated ledger canister, where it is determined how much stake each neuron has. 

Moreover, compared to the NNS where some configurations can only be changed by canister upgrades, in this open governance canister most configurations should be defined as parameters that can easily be configured at deployment and changed by proposals. This will allow each developer and community to tweak the governance rules to their needs.

### More design details
We next introduce some more details of the design, with a special focus on things that are different compared to the NNS governance canister. 

Note that some details have a remark *if feasible in a timely manner*. We propose that we implement these features in the first implementation if the effort is not too large. Otherwise, we propose to favor an earlier release and add those features in a next iteration.

### Proposals
In the NNS governance, proposals have both a type, determining what they will do exactly, and a topic, based on which neurons can follow other neurons in the decision making (liquid democracy). 
As each SNS will have very different use cases, we propose to omit the concept of proposal topics and facilitate following based on the proposal types.
Moreover, we propose that an open governance canister supports at least the following proposals by default: 
* A proposal to change the governance parameters 
* A proposal to upgrade one canister, that can e.g., be used to upgrade a dapp canister
* Motion proposals that facilitate discussions in the community but do not have any immediate, automatic effect

### Neurons
Regarding neurons, we propose:
- omitting the neuron attributes and methods that are specific to NNS use cases. 
- having the following neuron attributes (with motivation):
    - (If this is feasible due to storage restrictions) omit the ID of neurons and use the account of neurons on the ledger canister as the identifier instead
    - (If this is feasible in a timely manner) provide an access control list for neurons that specifies which principals can perform which neuron actions. For the first version, start with a simple logic that describes two keys similarly to the controller and hot keys in the NNS governance canister. Later, provide methods that allow defining valid access control lists by governance canisters and that allow neuron holders to change the access control of their individual neurons within these valid options.
    - (As in the NNS) The amount of staked governance tokens.
    - (As in the NNS) The time when the neuron was created.
    - (As in the NNS) The dissolve state of neurons specifying whether a neuron is dissolving, i.e., the timer when the staked tokens can be retrieved is decreasing, or non-dissolving, i.e., the time how much into the future the staked tokens can be retrieved is stopped and the age of neurons specifying how long the neuron has been in non-dissolving state.These concepts allow incentive systems where neuron holders that commit to the system for a longer time have more say or get more rewards.
    - (As in the NNS) Followees of a  neuron. This allows for voting with a liquid democracy, where neurons can choose to delegate their vote to other neurons.
    - (As in the NNS) maturity of a neuron which keeps track of the rewards that a neuron has collected. This allows governance participation to be rewarded.
 
* the following commands for managing neurons (similar to the NNS governance, except for omitting disburse_to_neuron which has an NNS specific use case):
    - *Claiming and refreshing* of a neuron. This is needed to stake a neuron and then top up a the stake of a neuron.
    - *Configuring* a neuron, including increasing the dissolve delay, start dissolving, and stop dissolving a neuron. This allows a neuron holder to choose the dissolve state and age of their neuron, which are explained above.
    - *Making a proposal*, *registering a vote*, and *configuring followers*, which allow a neuron to participate in governance decisions. 
    - *Retrieving and Merging Maturity*, which allows a neuron to mint the governance tokens corresponding to the rewards that it has accumulated and either retrieve them from the neuron or merge reinvest them by adding them to the stake of a neuron.
    - *Disburse* which allows a neuron holder to liquidate again the staked tokens.
    - (If this is feasible in a timely manner) Splitting and merging neurons which are convenient methods for neuron holders to organize their neurons.
- in contrast to the NNS neurons, making all neuron attributes public, including the controllers of a neurons. This simplifies the APIs and allows for more auditability. 
- omitting the proposals of topic *manageNeuron* that allow multiple principals to control a neuron and the associated use cases for the neurons (e.g., in access control and voting). Instead, allow canisters to control neurons.
- making some implementation improvements along the way.

## Security
We consider this to be a security critical feature, as the upgrades of dapps and the value of associated governance tokens are at risk if there are vulnerabilities. We thus plan that both the design and implementation will be reviewed by DFINITY security team. 

## Alternatives considered
Some different approaches that we could have taken and why we decided against them:

* We could have waited with releasing until we have the full SNS implemented. 
=> As argued above, we decided against this as it seemed to be a wish from the community to be able to use the single components as soon as possible.
* We could have decided to just reuse the NNS governance code.
=> We decided against this as there are some NNS specific things in the NNS governance canister that we do not need in the SNS. It also seemed to be a wish from the community to keep things as simple as possible, which supports this.
* We could have generalized the NNS governance code and then reuse it for both the NNS and the SNS. 
=> We decided against this as NNS upgrades are security critical and have to be considered carefully. Moreover, it would take more time to generalize the NNS code, taking into account all of the NNS specific components. Therefore, we favored using a new code base for SNS as this will allow for faster feature delivery.

## Risks and mitigations
As already discussed, there are security risks involved in this project. Therefore, this project requires thorough testing and security reviews and reasoning. We mitigate the risk of unforeseen findings by involving the testing and security experts early in the process.

## Community conversation & Timeline
The NNS team is ready to work on this feature!
To get the design approved by the community, we followed the following schedule:

* Jan 11-18th: Design discussion on the forum thread
* Jan 18th: Community conversation about the topic
* Jan 20th: Developer discussion on Discord
* today: motion proposal submission proposing the above design


## What we are asking the community:

* Vote accept or reject on NNS Motion
* Participate in technical discussions as the motion moves forward

Developer Forum: https://forum.dfinity.org/t/open-governance-canister-for-sns-design-proposal/10224/10 



Open Governance canister for SNS | Design proposal