Governance Assemblies

Greetings Shade community!

This post has been a long time coming and I’m happy I finally have some time to explain how our governance module works.


Traditional Governance

What makes the traditional governance implementation so special is its simplicity. You essentially have a module that allows token stakers to control internal protocol parameters as long as the majority of voters are in favour. Because of this, assemblies or funded groups operating inside the given protocol are technically managed and defined off-chain. This lack of support means that everyone, including the devs, have the same rights and must follow the exact same proposal rules. This is a perfect system on a theoretical level, but what happens when you have assemblies that work on time sensitive tasks or have changes that might need to be pushed sooner than the given proposal deadline?

Should all assemblies be subject to the same proposal creation rules? I disagree.


Shade Protocol Governance

In order to tackle the problem with keeping governance decentralized while also giving more on-chain individuality to assemblies is by implementing the features described below.

Governance Overview-Simplified.drawio

Component Explanation

Allowed Contracts

  • Name
  • Metadata: Description
  • Assemblies: List of allowed assemblies
  • Contract: Contract address

This is an on-chain list of contracts that governance is allowed to interact with, they have a list of the assemblies that are allowed to use this address. Ex: An assembly tasked with managing grant funds does not need to have access to Staking parameters


Assembly Message

  • Name
  • Assemblies: List of allowed assemblies
  • Message: Allowed contract interaction message

Assembly messages are a variable based pre-constructed message that further limits what an assembly can do with a given contract. These allow you to default a portion of the message to execute, meaning that we could make it so a message that updates a contracts config only utilizes one of the message fields abstracting them from changes that do not concern them.


Profile

  • Name
  • Enabled: Determines if the assemblies using this profile are active
  • Assembly Voting: When enabled, it allows assembly members to vote on the proposal before reaching public voting
    • Deadline: How long this phase lasts
    • Threshold: Required quorum
    • Yes Threshold: Required percentage of votes to accept
  • Proposal Funding
    • Deadline: How long this phase lasts
    • Required: Amount required to be deposited in order to advance to the next stage
    • Privacy: Determines if funder addresses should be kept confidential
    • Veto Deposit Loss: Percentage of deposited funds that are given to treasury if the proposal is vetoed
  • Token Voting
    • Deadline: How long this phase lasts
    • Threshold: Required quorum
    • Yes Threshold: Required percentage of votes to accept
    • Veto Threshold: Required percentage of votes to veto

Profiles allow for custom assembly requirements and scenarios, there can exist one profile for multiple assemblies meaning that you can group assembly proposal restrictions forcing them to behave similarly on that stage.


Assembly

  • Name
  • Metadata: Description
  • Members: The list of assembly members

The best way to visualize assemblies is by thinking they are flexible multisig wallets, since the members list can be modified and resized. Allowing for off-chain elections with on-chain results.


Proposal Flowchart

Below is a summarized explanation of how proposals will work with the given assembly structure.


Discussion

Now that the module is explained, I’d love to hear some feedback on how the module is structured and see some discussion regarding what assemblies do you think should be prioritized and what its associated profile should look like.

You can follow this template structure for assemblies if you like, to keep things ordered:

Assembly: Name

Description of the assembly

Potential Members: A list of people you’d think would be a good fit, can be left blank

Profile: Optional

  • Assembly Voting:
    • Deadline:
    • Threshold: %
    • Yes Threshold: %
  • Proposal Funding:
    • Deadline:
    • Required: SHD
    • Privacy: Yes/No
    • Veto Deposit Loss: %
  • Token Voting:
    • Deadline:
    • Threshold: %
    • Yes Threshold: %
    • Veto Threshold: %
7 Likes

First I want to say I love the module! I believe assemblies will prevent the protocol from getting derailed in the event of unfavorable regulations. That being said I really wish we could get our hands on traditional governance before adding this layer. I understand that assemblies need to be developed but it seems like we are putting the cart before the horse here.

4 Likes

Thanks for your work on this Guy!

1 Like

The module will still have a Public Assembly that acts as a general governance, meaning that anyone can create any type of proposal and must go through both funding and staker voting phases.

3 Likes

ah awesome, my belief is that where assemblies are needed will become apparent through public assembly. TBH im not exactly sure what all the assemblies options do exactly. Could you fill one out as an example assembly? Is the funding voting dependent on team?

1 Like

Surely,

Assembly: Assembly Management

Focuses on managing assembly parameters and aims to lead assembly member elections.

Potential Members: Key community contributors and devs that manage governance / staking to work as proposal parameter advisors.

Profile: Optional

  • Assembly Voting:
    • Deadline: 3 days
    • Threshold: 80%
    • Yes Threshold: 90%
  • Proposal Funding: Should require a large amount of SHD, trying to sabotage assemblies should come with a hefty price.
    • Deadline: 1 week
    • Required: A large amount of SHD
    • Privacy: No
    • Veto Deposit Loss: 80%
  • Token Voting:
    • Deadline: 1 week
    • Threshold: Should be updated depending on the average active token voters
    • Yes Threshold: 51%
    • Veto Threshold: 51%

Something to keep in mind is that proposal funding refers to some collateral that gets locked while the proposal is active. If the proposal goes through a veto then the people funding would lose a % of the required amount. If no veto were to happen then the funders get all their SHD back. The purpose of this is to punish those who make proposals that the community heavily disagrees with and considers dangerous or irresponsible.

3 Likes

awesome! that seems like the perfect place to start the assembly journey! The options make so much more sense now.

Assembly: Bond Management

Focuses on managing global bond parameters, as well as issuance of bonds. This assembly will be one of the most active working groups as bonds will be issued on a regular basis, especially if a Silk bonds market emerges. Powerful working group, needs to be watched carefully over time.

Potential Members: I would propose the initial following set of 5:

Ranger - experienced economics member.
Kyle - bonds dev
Dalton - DeFi strategist
Mike - dev operations lead
Fisco - protocol operations lead

Profile: Optional

  • Assembly Voting:
    • Deadline: 24 hours
    • Threshold: 50%
    • Yes Threshold: 50%
  • Proposal Funding: Should require a medium amount of SHD, as the community governance should be able to issue bonds at will.
    • Deadline: 1 week
    • Required: A medium amount of SHD
    • Privacy: No
    • Veto Deposit Loss: 60%
  • Token Voting:
    • Deadline: 1 week
    • Threshold: Should be updated depending on the average active token voters
    • Yes Threshold: 51%
    • Veto Threshold: 51%
1 Like

Assembly: Protocol Sustainability Assembly
(PSA, conveniently the same acronym as “Public Service Announcement”)

PSA aims to promote sustainable decision making for the long term adoption and success of both Silk and Shade Protocol applications. PSA is responsible for helping resolve conflicts between assemblies and assembly members - helping maintain decorum and community standards across assemblies.

Please note, the PSA is only allowed to create signaling proposals as well as participation in SigSwitch. No control over any funds with this assembly. Purely exists as a signaling assembly to the larger community.

Potential Members: Long term contributors that are not managing the ShadeDAO, but are trusted by the community to voice concerns about long term misalignment or negative assembly decision making. I would propose the inital following PSA composition:

  • Carter Woetzel - one of the original creators
  • Mohammed P. - one of the original creators
  • Joe M. - key BD relationship manager & advisor

Profile: Optional

  • Assembly Voting:
    • Deadline: 3 days
    • Threshold: 50%
    • Yes Threshold: 50%
  • Proposal Funding: PSA only creates signal proposals
    • Deadline: 1 week
    • Required: small amount of SHD
    • Privacy: No
    • Veto Deposit Loss: 50%
  • Token Voting:
    • Deadline: 1 week
    • Threshold: Should be updated depending on the average active token voters
    • Yes Threshold: 51%
    • Veto Threshold: 51%
1 Like

what does profile: optional mean?

Assembly: Proposal Quality Assurance Assembly

aims to promote quality discussion and decision making removing low quality proposals from general assembly.

Potential Members:

  • Carter Woetzel
  • Christian A.
  • zenopie

Profile: Optional

  • Assembly Voting:
    • Deadline: 1 day
    • Threshold: 50%
    • Yes Threshold: 50%
  • Proposal Funding: PSA only creates signal proposals
    • Deadline: 1 day
    • Required: small amount of SHD
    • Privacy: No
    • Veto Deposit Loss: 10%
  • Token Voting:
    • Deadline: 3 days
    • Threshold: LOW (this assembly should be easily over-ridden)
    • Yes Threshold: 51%
    • Veto Threshold: 51%

aka the janitors

Did I do it right?

1 Like

That’s actually an excellent idea - that assembly would need to define the standards for what is considered a “low quality proposal”.

2 Likes

Optional is just letting you know that specifying Profile is not necessary for this post, you can also just post a general assembly idea

1 Like

I think this is a very needed assembly. I like the potential members as they have proven themsleves across many fronts.

I like that @zenopie represents the community consinstently from the early days, has a critical eye and isn’t afraid of bringing the necessary respectul confrontation needed to prove quality proposals.

1 Like

I got some catching up to do here lol. Fascinating topics.

Assembly: Regulation compliance assembly

This assembly complies with ALL regulations possible

Potential Members:

  • Joe Biden
  • Gary Gensler
  • Rostin Behnam
  • zenopie

Profile:

  • Assembly Voting:
    • Deadline: 7 day
    • Threshold: 50%
    • Yes Threshold: 50%
  • Proposal Funding: PSA only creates signal proposals
    • Deadline: 7 day
    • Required: small amount of SHD
    • Privacy: No
    • Veto Deposit Loss: 0%
  • Token Voting:
    • Deadline: 14 days
    • Threshold: Medium
    • Yes Threshold: 51%
    • Veto Threshold: 51%

This assembly signals changes needed to comply with nation states. A no from the token voting community will block regulatory changes to the protocol. There is no veto deposit loss because members of this committee are tasked to propose changes needed regardless of their personal feelings on the issue.

potential members could be shade protocol and crypto experts as well as regulators themselves

I have created 2 assemblies, one has massive amounts of power and one has miniscule amounts of power, which one is which?

Assembly: Assembling Assembly

This assembly is tasked with helping assemble the assemblies for the community

Potential Members:

Anyone who enjoys assembling things in their free time. Legos, Kinects, robots, cars, etc

I’m sorry but this is the first thing that came to my mind lol :man_shrugging: :slightly_smiling_face:

3 Likes