🏛️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
| Entity | Description |
|---|---|
Assembly | A multisig with W number of participants that has access to modifying X amount of parameters or executing Y amount of actions based on Z restrictions - elections on a regular basis, sanity checks for accountability. |
Representative | An address that has votes delegated to it via a SHD staker. |
Tokenholder | An individual that stakes SHD and votes on governance proposals and elections. |
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.
| Assembly | Description |
|---|---|
Primitives | Manages core Shade primitives and application parameters. As Shade Protocol continues to launch applications that directly plug into the ShadeDAO, it will be the job of this assembly to optimize primitive parameters with respect to application growth, ShadeDAO revenue generation, and end-user experience. |
Treasury Management | Manages the issuance of bonds from the DAO, buybacks, trades, liquidity provision, reserves ratio, etc. Treasury management optimizes for ShadeDAO growth as well as stability of the Silk peg. |
Grants | Manages the community pool of the ShadeDAO with the goal of the creation of as many key Shade primitives as possible that adhere to the core principles of Shade Protocol as outlined in the original Shade Protocol whitepaper. |
Silk | Manages the research surrounding the optimization of Silk’s peg composition. Additionally, this assembly helps facilitate Silk peg migrations in addition to Silk adoption recommendations. |
HumanDAO | Aims to bootstrap and manage legal entities / individuals that are funded by the ShadeDAO to maximize the growth of Shade Protocol as it pertains to education, marketing, listings, community engagement, community growth, events, documentation, development, hackathons, and any other conceivable component of a protocol that pertains to human capital. |
Community | Aims to raise community-level concerns to all of the respective assemblies, and help facilitate dialogue and transparency between the community and the respective assemblies. |
Protocol Sustainability | Aims to promote sustainable decision making for the long term adoption and success of both Silk and Shade Protocol applications. Protocol Sustainability is also responsible for Shade Protocol governance process management and the creation of best practices for governance. It is tightly partnered with the community assembly and responsible for coordinating cross-assembly decision making. |
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
