Open Governance canister for SNS | Design proposal

One of my main concerns with the new design (which I think is fantastic BTW) is that it is still somewhat forcing us into a staking model with lockups and rewards. What if we just want a simple token voting SNS? No staking, no lockup periods, no voting rewards…just simple coin voting. For ICDevs I imagine that’s all we’d want at least to start. Not all projects will want the “token” to accrue value and become a tradeable asset, or at least I don’t think we should force everyone into that model. Forcing lockups and rewards seems to do that.

8 Likes

I’d love that. We were going for that with Bounty - ICDevs.org Generic DAO - Axon Fork. We don’t have a token so staking doesn’t really make sense. We need a system where we can hand out votes to known-real people and we don’t really want those votes to be transferable…so the token model works but doesn’t quite fit.

2 Likes

My understanding from @lara’s talk is that you can emulate that by setting dissolve delay to 0 for everyone and removing any age or other bonuses. These should be governance parameters that can be tweaked, I think.

Hey everyone, just a friendly reminder that @lara will be leading a developer discussion today on Discord at 8:00am PST. Hope you can make it!

2 Likes

Thanks for the feedback.
Yes, as @jzxchiang pointed out, some of this should be achievable by setting the parameters correctly.
For example, setting the dissolve delay required to be eligible to zero.
Also, at least long term, rewards will be optional so each SNS can decide when to burn and mint new tokens. I am not sure if it has been decided whether this feature is realised in the first version, but thinking about it, it shouldn’t actually be that hard to make rewards optional.

After this feedback, I would like to at least consider including this in the first version.

3 Likes

Hi all, just an update from my side:
as promised in the first post, we plan to submit a motion proposal with the above design, now that we had the different conversations.
@diegop kindly agreed to help with this.
In order to give the proposal enough visibility, we plan to send it early next week rather than so shortly before the weekend.

Have a great weekend and look out for the proposal next week!

4 Likes

Update:

Proposal is live!

7 Likes

Big concern! How will people use this thing without a front-end supplied? Are we supposed to all create our own front-ends to even start experimenting with this? Even a simple front-end would be nice to have

8 Likes

Thanks for bringing up the concern.
Note that this particular project is just about the governance canister.
A frontend is planned but will be done separately.
I am currently following up internally regarding when we think we can have that.

3 Likes

I’m just worried no one (really it will just be much harder) will use this and try it out without a front-end. And the point of pushing things out in pieces is to get community feedback.

1 Like

That is certainly one goal.
Another goal is also to already make the code available to developers who might want to reuse parts of this to build their own governance / DAO etc.

But it is valuable feedback that I happily take back.

4 Likes

Is there any implementation started for this beyond the proposal and this thread that I can take a look at?

1 Like

Hi all, please find the design proposal for the next stage of the SNS project here.
Looking forward to your questions and feedback!

2 Likes

Yes, the implementation is started. It is still very much work in progress, but you can follow along here https://github.com/dfinity/ic/tree/master/rs/sns

2 Likes

I see a pathway to set the SNS canister to call a remote canister to call a function. I’d like something like:

type RemoteCall {
principal: Principal;
function: Text;
data: Blob; };

In motoko this could use the call_raw functionality coming in 0.9.1. This would allow services canisters to mark the SNS canister as the “Admin” and then the sns could vote on functions to call on various canisters(not just the SNS canister which I think is the current set up).

I’m working on the spec for a service right now that is trying to be governance service agnostic and just assign a governance canister. As long as that canister knows how to call the issue_command function you can use the SNS or something simpler. It would be great if the SNS supported this. I know there are issues with getting stuck on a bad behaving canister, but maybe you can not wait for the await? Or maybe it is a parameter to the type?

1 Like

Hi @skilesare ,
it is definitively the plan that the SNS governance can call another method on a canister and that the SNS can then be used to execute arbitrary proposals.
For the very first version, we prioritised that a SNS should be able to upgrade another canister, e.g., the dapp (which is also a call to another canister), upgrade SNS canisters, change the SNS parameters, and have motion proposals. Next we would tackle the generic proposal execution (which I think is what you are asking for), but this might not be ready in the very first version in Q1.

Could you elaborate on what you mean by “the issue_command function”?
If I understand you correctly you would like to have the following functionality: a canister that just has a method and specifies that the SNS governance is allowed to call that method. The SNS governance can then call this method as a result of a proposal. Is this right? If so, I think this is what should be possible with the “generic proposal execution” that we envision.

2 Likes

Sounds right! It will be a good feature to have.

2 Likes

@lara Which token standard will SNS governance tokens use?

4 Likes

It will user the same ledger as the NNS.

1 Like

I think he wanted to know what coin standard will be used for coins that make use of SNS, such as you have ERC20 or BEP20 token standard.