🏛️Governance
A description of the functionality of Shade Protocol governance.
The ability to scale a protocol over the long haul is directly tied with its ability to scale governance. The key goal of governance is to managed the protocol effectively in a way that reflects the decentralized SHD tokenholder community. Governance models in DeFi have struggled with the following:
Efficiency
Decentralization
Accountability
Transparency
Fluid governance that optimizes for the speed of management and implementation of change within a DAO while simultaneously having end accountability from baseline token ownership creates an optimal end state. Shade Protocol governance model is based on a variety of assemblies and representatives to empower the fluidity of Shade Protocol governance.
Building Blocks
Assemblies
The role of assemblies is to perform a whitelisted set of actions in a way that benefits the protocol - these actions are bounded by system wide governance restrictions as set by tokenholders and representatives.
The role of assemblies is to perform a whitelisted set of actions in a way that benefits the protocol - these actions are bounded by system-wide governance restrictions as set by token holders and representatives.
Foundational Governance
Current Shade Protocol governance proposal parameters, which are subject to change, are as follows:
Deposit period - 1 week
Voting period - 1 week
Minimum deposit amount - 100
SHD Quorum - 25%
Threshold - 50%
Veto - 33.4%
There are five stages to on-chain governance proposals on Shade Protocol: submission, deposits, voting, tallying, and implementation. Submission can be done by any user, with the caveat that nothing is broadcasted on-chain until a proposal reaches the minimum deposit amount This is in place to protect Shade Protocol from proposal spam. Anyone can contribute to the minimum deposit amount. If the proposal does not reach the minimum deposit threshold, deposits are refunded. If the proposal is approved or if the proposal is rejected but not vetoed, the deposits will automatically be refunded to the respective proposal depositors. It is critical to note that if a proposal is vetoed with a supermajority, then the deposits are burned. After reaching the minimum deposit required, a one week voting period begins. During this timeframe, bonded SHD holders are able to cast their vote with one of four options - yes, no, no with veto, and abstain. Only bonded tokens can participate in Shade Protocol governance; this encourages users to bond their tokens to the network, which is an essential part of securing the network. Voting power is measured in terms of bonded SHD tokens.
Delegators inherit the vote of the representative they are delegated to unless the delegator casts their own vote (which automatically overwrites the representative’s voting decision). Tallying the results of a proposal vote can result in an accepted proposal if the following requirements are met: quorum, threshold, and no veto. The quorum requirement programmatically checks that more than 25% of total bonded tokens participated in the vote by the end of the one week voting period. The threshold requirement programmatically checks that more than 50% of tokens that participated in the vote, after exclusion of abstain votes, voted in favor of the proposal. The no veto requirement confirms that less than 33.4% of bonded tokens that participated in the vote, after exclusion of abstain votes, vetoed the proposal. Finally, the code the proposal wishes to modify is altered by developers of the network and implemented during the next “patch” of Shade Protocol secret contracts.
Foundational governance can propose changes to any modifiable parameter as well as perform any action that an assembly has the ability to perform.
Sanity Checks
To defend against rapid decision making from multisigs that may not be representative of the larger token governance holders, Shade Protocol introduces “sanity check” proposals that resolve within 24 hours and require a greater than 50% approval with a 7.5% quorum so that the execution request from the respective assembly can be performed. Sanity checks help defend against malicious multisig activity, while still empowering end token holders to have a direct voice in the daily activities of the various Shade Protocol governance assemblies.
Sanity checks also help with the legal risk of centralization accusations attached to any given multisig, as ultimately, SHD token holders are still the decentralized stakeholder with direct control over the entities that partake in the assembly multisigs as well as approval of daily activities of the respective assemblies. Finally, sanity checks provide an on-chain archive of multisig activity and decision making - bringing a degree of transparency and methodology to Shade Protocol governance that is conducive to healthy and consistent decision making.
SigSwitch
SigSwitch is the mechanism that is needed for the Community assembly to use its ability to add or remove individuals from assemblies (separate from assembly elections). SigSwitch is necessary in order to resolve inter-assembly conflicts, help adherence to strong community feedback and signal proposals, and resolve individual or assembly misconduct.
Misconduct is defined as the following:
Refusal to provide transparency of conversations to the Community Assembly
Refusal to provide periodic updates and the justifications behind the policy strategies of any given assembly or individual
Malicious assembly or individual decision making
Inept assembly or individual decision making
Malicious or inept interpersonal conduct or communication
SigSwitch steps are formalized as follows:
A SigSwitch is initiated by the Community assembly specifying the modification of an existing assembly. Note that both the Community assembly and the proposed modified assembly are unable to vote on the SigSwitch.
Individuals that vote on the SigSwitch are those that make up the remaining assemblies not impacted by the SigSwitch vote
If greater than 33% of eligible assemblies vote yes, the assembly is modified.
Elections
Elections of multisig entities happen on a bi-annual basis. Multisig entities are voted on in sets, as opposed to individuals that are part of the multisig. The following is an example:
Choice 1: Bob, John, James
Choice 2: Bob, John, Jill
Choice 3: James, Johanne, and Greg
Set based voting simplifies the end-vote experience. With a starting set of 7 assemblies with 7 entities part of each assembly, users would potentially need to vote 49 different times. Instead, users need to only vote 7 times, across a set of decisions. Front-ends hosted by the Shade DAO Institute and any respective Shade Protocol development teams should help assist with voting and education surrounding the entities on the respective ballots.
Conclusion
Shade Protocol governance uses assemblies to optimize the fluidity of DAO wealth and decision making management while still maintaining foundational governance accountability via periodic elections, sanity checks, representatives, and community assembly participation. With this structure, Shade Protocol is designed to scale well beyond the initially imagined scope in reaction to economic success and yet-to-be-imagined assembly responsibilities. Shade governance stands on principles of primary rights to digital sovereignty - empowering users from around the globe to have digital independence, digital privacy, transparency by choice, and financial access to Shade primitives.
Last updated