Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal level permissions #161

Open
starpause opened this issue Apr 20, 2022 · 2 comments
Open

Proposal level permissions #161

starpause opened this issue Apr 20, 2022 · 2 comments
Labels
C-discussion Category: Discussion, leading to research or enhancement C-Enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@starpause
Copy link
Contributor

There are not proposal level permissions in the sputnik contracts. It's possible to give different groups in one DAO access to different actions (AddProposal vs Vote), but to have 2 different groups allowed to vote on 2 different proposals you need to set up 2 DAOs (could be sub daos or partner daos). We have gotten several requests for proposal level permissions from users.

@starpause starpause added the C-Enhancement Category: An issue proposing an enhancement or a PR with one. label Apr 20, 2022
@TrevorJTClarke TrevorJTClarke added the C-discussion Category: Discussion, leading to research or enhancement label Apr 22, 2022
@TrevorJTClarke
Copy link
Contributor

TrevorJTClarke commented Apr 22, 2022

@starpause this is definitely something that needs consideration.
Here's the current new spec: https://github.com/near-daos/sputnik-dao-contract/wiki/%5BDRAFT%5D-DAO-Data-Model-Architectures#dao-proposal-data

I had originally added permissions & voting requirements at the proposal level - but here's the questions that need answering before officially supporting proposal level permission configs:

  1. Who can define permissions on the proposal & at what level? Consider a generic community member proposes something and sets permissions on a proposal that denies a more admin council group, or allows more permissions that could break future governance. REF
  2. Vote policy could make more sense, however could be tedious to define given complex group definitions. Consider a proposal has voting policy to define weight/thresholds that are different than main DAO config. The flexibility is great for low value or non-collateralized proposals, but could be significantly dangerous for value/collateral involved proposals. Imagine setting threshold and quorum to 1% and transferring entire available DAO balance. With great flexibility comes greater attack surface.
  3. Optionality could provide a compromise if a solid use-case is provided. For example, if a simple signaling proposal (Poll) was the only proposal type that accepted policy or permissions adjustments, that could be cause for support.

I welcome more thoughts and opinions on this!

@ctindogaru
Copy link
Collaborator

I agree with @TrevorJTClarke on this one.

Proposal level permission can be a nice addition to the current governance model, but they open the door for horrendous attacks. One can simply create a Transfer proposal to transfer all the money from the treasury to a dedicated account. With proposal level permission, it can be very easy to achieve that. Even if the council has 1000 members that can vote, the proposal creator can set up the proposal permissions to only 3 members which are his allies. It's enough for 2 members to approve the proposal and the money from the treasury would be lost in the blink of an eye.

@starpause, why exactly do people need this? Do you know any specific use cases?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-discussion Category: Discussion, leading to research or enhancement C-Enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
Status: No status
Development

No branches or pull requests

3 participants