After discussion and feedback from both client teams and the community, @Will and I have put together a revised Threshold DAO proposal.
The fundamentals of the v2 proposal are very similar to the v1 proposal. The primary differences and improvements as described throughout this document involve:
- Proposal thresholds
- Vote delay
- Emergency security
- Veto power
For easier readability, deletions have been
struck through. New sections are marked with , and additional language in existing sections is bolded.
The upgraded Threshold network will offer the best of what the Keep and NuCypher networks offer today. As our communities continue to merge, we’ll need a single community DAO to govern the new network.
There are two major constituencies in the Threshold network: active stakers and token holders. Both NuCypher and Keep governance today privilege active stakers.
We’d like to propose a bicameral DAO with an elected multisig council to govern the new network, addressing both groups of stakeholders and better aligning all participants. The DAO, based on Compound’s
GovernorBravo, will give the bulk of governance power to active stakers, with the exceptions of
- treasury management
- token issuance
- governance system changes
Elected Multisig Council:
- staking rewards management
- proposal vetos
This design follows the principle that no party should be trusted to “vote themselves a salary” and implements meaningful checks on power within each portion of the network’s governance. Stakers are the best positioned party in the network to approve contract upgrades and other changes relevant to applications on the network, and are required to be highly engaged to mitigate slashing and other concerns.
The goal of this system is to enable the combined Threshold community to propose, vote on, and implement changes that support and improve the upgraded network.
The bulk of this DAO will be implemented using two instances of GovernorBravo and a separate multisig council.
For those unfamiliar, GovernorBravo is the latest iteration of Compound’s DAO which is also used to power a number of other projects in the space. Documentation for the contracts can be found here.
Token Holder DAO
The first instance of GovernorBravo will be the token holder section of the DAO. T holders will be able to add proposals on-chain, delegate votes, and execute proposals.
Initially, vote power in the Token Holder DAO is accrued by liquid T holders, T stakers and those who deposit T to coverage pools. If possible, in the future vote power accrual will expand to other areas where T is put to work including LPs on AMMs.
The Token Holder DAO will manage the treasury and be the owner of the T token contract. The Token Holder DAO will have the power to deploy the treasury, and mint additional T tokens. Its minting powers can be restricted, enforcing a hard limit on any inflation.
The second instance of GovernorBravo will be the Staker DAO. Stakers will be able to add proposals on-chain, delegate votes, and execute proposals.
The Staker DAO will have a major modification over GovernorBravo as deployed today being that vote power will be determined by stake weight on the network without the introduction of a separate token.
The v2 DAO proposal introduces delegations for the Token Holder DAO. This means that T holders will be able to delegate their vote power regardless of if the T is wrapped from KEEP or NU. The StakerDAO will also support delegations of stake weight.
Proposal threshold is the amount of T vote power or stake weight a community member must own to be eligible to submit proposals onchain. The amount can be reached through delegations. Proposal thresholds are critical for the Threshold DAO because they help safeguard the network against dangerous proposals and act as an enforcement layer for what proposals make it onchain. Without a proper proposal threshold anyone can go rogue and bypass the temperature check period in the community by simply submitting a proposal onchain.
The initial proposal threshold on both the TokenHolder and StakerDAO will be set at .25% of vote weight and stake weight accordingly.
When applicable we plan to use delegations to ensure elected council members and other core community members hold enough vote weight to submit proposals on-chain in either instance. After a proposal passes a temperature check these community members will meet requirements to move proposals onchain. In this sense, council members and core community members will act as quasi gatekeepers in the Threshold DAO ensuring that the quality of proposals that make it onchain remain high. This allows our governance system to remain committed to reducing engagement friction while still safeguarding against potentially dangerous proposals.
The Token Holder DAO holds the power to adjust proposal threshold numbers in both instances of GovernorBravo if the need arises.
Quorum is the amount of vote required in favor of a proposal for it to be successful. After quorum is hit a proposal passes if the majority of votes fall in favor of the proposal.
During community discussion around the v1 proposal it was decided to implement lower quorum requirements in both sections of the Threshold DAO compared to other relevant DAOs to avoid self imposed blockers in our community for strong proposals passing.
The initial quorum on both the TokenHolder and StakerDAO will be set at 1.5% of vote weight and stake weight accordingly.
The TokenHolder DAO holds the power to adjust quorum overtime as the network and its governance grows and the need arises. Furthermore, the community can explore ways to set different quorum requirements for different types of proposals in the future similar to the AAVE Governance Module.
A vote delay is the amount of time between a proposal’s submission on-chain and the vote period officially beginning. During this time community members will be made aware that a proposal has passed the temperature check period and the onchain vote is about to begin. The vote delay will be initially set at 2 days for both the Token Holder DAO and the Staker DAO. 2 days is current industry standard.
We are proposing a nine seat multisig council that retains the power to manage per application staking rewards on the new network. This is a critical governance role on the upgraded network, and delegating this responsibility to an elected council services the upgraded network and combined community in many ways. First, it sets up our governance system in a manner that avoids continuous community friction between parties with competing application level interests on the network. Second, individual accountability for critical network wide decisions is better upheld when executed on a council than an entire token holder constituency. Simply stated - our community needs to ensure these decisions are made in a responsible and transparent manner. Under this proposal the community council will meet quarterly to make per application rewards adjustments on the upgraded network.
The inaugural upgraded network council should hold fair representation from both existing communities. Thus, we propose that the Keep community elects 4 members and the NuCypher community elects 4 members. The final seat will be determined by an appointment or vote by the Keep and NuCypher teams.
Terms for the multisig council will last for one year with elected members expected to be contributing members of the upgraded network community for the duration of their term. Second term elections will take place before the inaugural term ends. If a council member decides to step down, a by-election for the seat may be considered by the community. There is no term limit for council members.
The multisig council is controlled by the token holder DAO and council members can be removed early subject to a DAO vote if necessary. For example, if a council member fails to fulfill their duties, acts in a manner that harms the network or is inconsistent with the wishes of the community, they can be removed via a DAO proposal prior to their term ending.
The elected council will hold the power to veto any proposal that passes from either the Token Holder DAO or the Staker DAO. This is intended to be an extra security mechanism in the event that a dangerous proposal passes in either DAO subsection. The exact process will be determined later as the DAO approaches a launch.
Emergency Security Developer Multisig
This ESDM has been removed from the Threshold DAO Proposal v2 as a result of community discussion. For for an explanation on why this happened and to see what the next steps are please review this forum post - Threshold DAO v2 Proposal Edit - Removing the Emergency Security Developer Multisig - #4
Proposal Community Process
… or, “How a proposal becomes a law”
Below is a potential process for TIPs, or “Threshold Improvement Protocols”. As community discussion continues to form around vote processes and governance cadence, this process will always be subject to change through a Token Holder DAO proposal.
Step One — Temperature Check
A Threshold community member posts a potential proposal on the Threshold governance forums. Community members who post the initial proposal are encouraged to get active in Meta governance discussions within the community on forums and in Discord to earn support for the proposal. There is no minimum token threshold required to create a new proposal on the forums. Temperature checks require offchain snapshots to pass. If a proposal receives majority support during the temperature check snapshot it is eligible to move onto the second step. Community mods reserve the right to moderate proposals during a temperature check by simply deleting the proposal from the forums.
Step Two — Proposal Creation
A community member holding enough vote weight or stake weight submits the proposal on-chain. The proposal enters a two day vote delay period before voting officially begins.
Step Three — Vote Period
Proposal voting remains open for 10 days. If the proposal passes according to requirements outlined above it moves onto step four. If the proposal fails it is canceled. Creators and supporters of the proposal may bring a modified proposal forward again but it must be sufficiently different and pass requirements outlined in step one.
Step Four — Execution
Once a proposal passes, it will be executed. Proposals are executed by the particular GovernorBravo instance hosting them.
Keep and NuCypher are community driven projects and this will continue with the upgraded network. This proposal is a second iteration of the governance system for the upgraded network. We encourage community members to review, ask questions, discuss and add ideas in the thread below. If there is no significant push-back, this proposal will be taken to a snapshot in both communities, moving us one step closer to a complete protocol merge.