[RFC] Governance V0 for Shutter DAO 0x36

Shutter DAO DAO Proposals
1

[RFP] Governance V0 for Shutter DAO 0x36

Authors: DAOplomats.eth (@Baer_DAOplomats)

Draft Date: 2024-01-24.

Summary:

This proposal proposes the following.

  1. Adopt and formalise the Governance V0 and proposal lifecycle for ShutterDAO.
  2. Adopt a standardised general proposal template for Improvement Proposals.
  3. Adopt a temp check mechanism to streamline the on-chain proposals.
  4. Implement voting strategies for the Tempcheck.

Motivation.

Being a truly decentralised DAO launched after the Shutter Blueprint, the DAO lacks the basic processes needed for proper functioning. We currently lack a temperature check mechanism. The Proposal strategy does not have any spam filtration mechanism for proposals, as the proposal threshold is set to 0.

Furthermore, it is currently unclear how long a proposal should be discussed before it’s moved to vote, or even if it should be posted to the forum before it’s on-chain.

This proposal aims to determine the best way for a proposal to move from an idea to a formal proposal and a ShutterDAO Improvement Proposal (SIP). This proposal seeks to combine information posted in the DAO launch blueprint and the best practices in the DAO ecosystem to set this DAO up for success.

Background

Setting the stage

The governance discussion for ShutterDAO 0x36, a ShutterDAO implementation, will be hosted on https://shutterdao.discourse.group/ or on the forum officially approved by the DAO. ShutterDAO utilises on-chain executable proposals through the Fractal framework and Safe. Anyone can sign up for the Governance forum or Discord and engage in the conversation.

Current parameters

  • Voting strategy: simple majority (50% + 1 smallest unit of a token)
  • Quorum: 3% of all tokens
  • The minimum amount of tokens required to propose: 1
  • Voting period length: 72 hours
  • Execution period: 72 hours
  • Cooldown period: None

DAO Governance Proposals [SGPs]

The DAO currently doesn’t have a standardised proposal template, but any members can take part in the discussion on the forums. The token holders then vote on the proposals.

Specification

The Proposal Lifecycle.

This proposal aims to adopt a general proposal template to standardise the proposals for the DAO, and divide the proposal lifecycle into temp checks and ShutterDAO Proposals (SIP)s.

Proposal Lifecycle

[Idea] :arrow_right: [Draft RFC] :arrow_right: [RFC Formalised] :arrow_right: [Temp check Poll] :arrow_right: [On/Offchain SIP] :arrow_right:[Accepted/Rejected]

1600×178 18 KB

Phase 0: Ideation

The purpose of this phase is to gather community sentiment on the author’s idea. Unique ideas can use the #idea tag on the forum and have their thread. Phase 0 proposals are generally ideated in informal settings like Discord chat or Telegram groups. This phase could include gathering community support on the specifications of a potential RFC with multiple in-text polls.

Time: Open

Phase 1: Request for Comment

During this phase, proposal authors could request official community sentiment by formulating the idea in a Request for Comment (RFC). RFCs should follow the prescribed template.

[Link to template]. (Pending DAO Approvals)

During the draft stage of the RFC, the author shall include community feedback and update the proposal accordingly. The Draft RFC status aims to gather adequate feedback and support to attain soft consensus, allowing us to proceed confidently with a formal proposal without the risk of it being immediately rejected.

Time: Open

Off-chain Temperature check through Snapshot

This proposal suggests adopting a snapshot space for temperature checks with the following parameters.

  • Voting strategy: simple majority (50% + 1 smallest unit of a token)
  • Quorum: 1% of all tokens
  • The minimum amount of tokens required to propose: 1000
  • Voting period length: 72 hours

Since Snapshot is off-chain and gasless, there is a higher chance of spam, which can be mitigated with a minimum token requirement.

After completing Phase 1, the author can move an RFC to a Shutter Improvement Proposal, an SIP.

Phase 2 SIP Proposals

Depending on the nature of the SIP, be proposed on-chain using the Fractal framework of off-chain with Snapshot. For more info see the table below.

Proposal Platform Proposal type
[OnChian] Fractal
Changes to governance processes, e.g Quorum, Proposal thresholds etc
Modifications to on-chain voting parameters
Updates to Keyper set parameters
Transfer of funds
[Off-chain] Snapshot
Temperature checks
Requests For Proposals (RFPs)
Letter of Intents with non-binding outcomes
Proposals which don’t have any on-chain consequences to ShutterDAO 0x36, eg: Shutter Integration supports, use of 0x36 Brand, etc

Current parameters

  • Voting strategy: simple majority (50% + 1 smallest unit of a token)
  • Quorum: 3% of all tokens
  • The minimum amount of tokens required to propose: 1
  • Voting period length: 72 hours
  • Execution period: 72 hours
  • Cooldown period: None

Depending on the voter turnover and weight, the minimum amount of tokens required to propose can be increased.

Next Steps

  1. Gain community sentiment
  2. Move to Snapshot voting.

Disclaimer

No Guarantee of Results; and Limitation of Liability:

This proposal is neutrally presented based on current community sentiment.

DAOplomats are not compensated for this proposal in any manner. We are not associated with any of the parties mentioned in the proposal above.

Given the evolving nature of DAOs, there’s no assurance that the proposed changes will yield the intended results.

The author(s) and associated parties are not liable for any outcomes or damages from this proposal’s implementation or lack thereof.

Copyright

Copyright and related rights waived via CC0.

5 Likes
2

yes, practical one! best way for a proposal to move from an idea to a formal proposal

2 Likes
3

This proposal will be updated with in accordance with

And moved to on chain vote, if no further comments.

2 Likes
4

Hi, I think an off-chain vote might be a better fit since no on-chain transaction should be needed for the proposal.

3 Likes
5

Thanks for this proposal @Baer_DAOplomats ! Kleros Labs will support it as it will allow the DAO to have a clear process and to be more efficient.

We agree that an off-chain vote on Snapshot should be enough for this one.

Kleros Labs

1 Like
6

before moving this proposal further, I need a consensus on whether we should be using the [SIP] prefix as in the proposal or [Onchain] / [offchain] prefixes.

the takeaway from the Snapshot proposal from @5pence for me is that we can link ‘‘Official’’ Snapshot to fractalframework.xyz, for that we indeed need an on-chain proposal.

and this proposal also askes for a 1K proposal threshold for the snapshot, as it can be spammed easily, if the Admin isn’t willing to update it off-chain we need to make an on-chain tx to do that!

1 Like
7

I think that in this early-stage of Shutter DAO 0x36 the SIP process is not needed as it would also require designated group of people assigning the numbers.

Also, deciding on a governance process for a Shutter DAO can be separated from canonizing the Snapshot space. This especially since the Snapshot space decision could be seen as a quite straight-forward choice, whereas the process choice could have more discussion and input from the community, possibly leading to changes, etc.

1 Like
8

Thanks @Baer_DAOplomats .

Are there any remaining discrepancies between this framework and the other framework proposed in the forum thread posted here: A Shutter DAO Governance Process Document ?

Also, I’d recommend raising the proposal threshold to higher than 1,000. I’d think the DAO would want a minimum of 5k, or even 10k - 20k delegated votes being an even better threshold for a safer solution. We could also have a higher threshold for onchain votes vs. social votes too.

1 Like
9

This proposal is moved to a snapshot as an RFP.

https://snapshot.org/#/shutterdao0x36.eth/proposal/0xfbd94f8b30df1581b0b7a8790ecb55cf13e260b075bb6a1d06c73aa22cbe768a

1 Like
10

Hey @5pence, thanks for the feedback,

There aren’t many differences between this framework and ‘A Shutter DAO framework’ The only significant differences are in terms like ‘RFC -Request for Comment’ vs RFP- Request for feedback Proposal, or use of term SIP for proposals on chain and on snapshot that are either RFC and temp check.

In the Edit history, you can track how the original proposal has changed according to the ‘A shutter DAO framework’.

I agree with you on increasing the threshold; our initial idea was to raise it to 1M for on-chain proposals. But at DAOplomats, we weren’t sure how the participation of voters in the governance might be, and we took the least amount of Airdroped tokens.

As mentioned in the proposal, we can increase the threshold once we get more data.

1 Like
11

@Baer_DAOplomats Thanks so much for putting together this Governance V0 framework. A couple questions and comments.

Effective Date

What would be the effective date? Shutter DAO 0x36 has voted to run an LBP in mid February, and Artis has recommended Shutter DAO 0x36 run the LBP on Feb 21-25. In order to reach this goal and to quickly respond to events just after the LBP, Shutter DAO 0x36 may need to use the current de facto framework, which is similar but more streamlined. I suggest either:

a) an effective date of 1 April 2024., or

b) use the de facto process for all LPB / market making related decisions and the new framework for all other decisions

Proactive Grant Votes

How should Shutter DAO 0x36 handle proactive grant votes? Shutter DAO 0x36 may want to approve a grant, but only deliver payment after the grantee has achieved the stated objectives/milestones. I suggest Shutter DAO 0x36:

a) conduct proactive grant votes with binding outcomes on Snapshot, and

b) conduct administrative votes on Fractal.

Administrative Votes

How should Shutter DAO 0x36 handle administrative votes? For example, Shutter DAO 0x36 has voted to provide a proactive grant to Artis’ for market making services for 6 months. Shutter DAO 0x36 will pay Artis each month. I suggest Shutter DAO 0x36 implements a separate, streamlined process for administrative votes.

The Term “RFP”

I was initially confused by the use of the term “RFP” in this context. I normally see RFP used in a commercial/procurement setting. It took me a while to understand that you were using RFP as a stage in this framework. I suggest Shutter DAO 0x36 choose distinct terms and acronyms for these things.

1 Like
12

Did we skip the [Temp Check Poll] stage on this one, or did I miss it? Or is this Snapshot vote the Temp Check (not a poll) and if successful the proposal would go back through again as a phase 2 onchain vote, or perhaps instead another off chain snapshot vote?

I believe I too have the different assumption of the RFP acronym as I don’t understand how it’s being used as a stage.

@Baer_DAOplomats - I noticed the proposal is already live for voting, but some of the feedback seems to have very valid points we might still need to clarify.

My general sense is that this proposal describes some good practices, as does the other post, A Shutter DAO Governance Process Document, but there’s still some iteration needed before it’s the right formal process to adopt as a DAO.

1 Like
13

This is the the temperature check stage for the entire proposal according to the framework, if not I would have added [off chain] prefix. I haven’t added temperature check polls for the specific points in this proposal as it would have been an overkill.

@Loring Request for Comment [RFC], is a common practice in the DAO ecosystem. DAOs like 1inch, (1RC) and Aave (ARFC) use these terms. If it makes sense we can use [Temperature check] as a blanket prefix for all non SIPs.

@5pence sorry if you think that this proposal is move forward without incorporating all feedbacks. This proposal is live for more than 15 days and I have pinged multiple times for feedbacks.

And the feedback only came rushing after the vote has started.

1 Like
14

@Loring the proposal should be valid once it’s passed as off chain vote. But any proposals pre Gov V0 will be excluded from this process.

The framework enables you to skip all parts till the snapshot and move to on chain vote. We haven’t changed much here. Or are suggesting LBPs should skip snapshot and move to on chain ?

Transfer of funds should be an Onchain proposal.

There are already tools available to streamline payments for service providers. Instead of a monthly Onchain vote, we can set payment streams through Superfluid or splits.

The A shutter DAO framework also suggests using transfer of funds on chain and running binding commitments on snapshot isn’t a great idea if on chain proposal options are there.

1 Like