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.
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: %