I propose to use this new thread to discuss a new proposed design for the open governance canister that can be used for implementation of the service nervous systems (SNSs).
Similarly to how the Network Nervous System (NNS) is the open tokenized governance system that controls the Internet Computer blockchain (IC), service nervous systems (SNSs) are algorithmic DAOs that will allow developers to create decentralized, token-based governance systems for their dapps.
Decentralized control and tokenization enables the introduction of new incentive systems and use cases that have the potential to set dapps apart from traditional applications. We refer to this article for more background on how SNSs will empower Dapps to leverage the full potential of the IC.
The goal of this project is to provide a first implementation of an open governance canister that will then be used to realise the service nervous systems (SNSs).
More concretely, this release’s goal is to provide an “out of the box” governance canister implementation that
- Can be used to realize the SNS (see next section)
- Can be used by anyone looking to implement another kind of DAO for their dapp, either by using the governance canister and integrating it with other canisters or by just taking the governance canister code as a basis and evolving it to another kind of governance
We presented a first proposed SNS design in October 2021. The community’s feedback was that that SNS design was rather complex and does not leave a lot of freedom to developers to configure a DAO to their needs. Moreover, 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, we propose the following new approach:
- 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
- Evolve these single building blocks to arrive at a concrete implementation that can be used without engineering efforts
- 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
More concretely, we propose the following initial stages:
- Improve the NNS ledger canister so that it can also be used for other tokens
- Implement a governance canister (the design presented and discussed here)
- 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)
- 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)
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, we propose 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.
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.
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
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 neurons’ ID and use the neurons’ account 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 neuron’s dissolve state 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 neuron’s age 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) A neuron’s followees. This allows for voting with a liquid democracy, where neurons can choose to delegate their vote to other neurons.
- (As in the NNS) A neuron’s maturity 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 neuron’s stake.
- 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.
- Spawning and Merging Maturity, which allows a neuron to mint the governance tokens corresponding to the rewards that it has accumulated. The former allows the neuron holder to retrieve the rewards as tokens in a new neuron with a small dissolve delay and the latter allows a neuron holder to reinvest the rewards by adding them to the neuron’s stake.
- 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 neurons’ controllers. 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.
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’s security team.
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.
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.
The NNS team is ready to work on this feature!
To get the design approved by the community, we propose the following schedule:
- Jan 11-18th: Design discussion on this forum thread
- Jan 18th: Community conversation about the topic
- Jan 20th: Developer discussion on Discord
- (a few days later): motion proposal submission proposing the above design, potentially adjusted with the feedback from Steps 1 - 3.
Looking forward to hearing your inputs on this!