Community discussion around the v1 DAO proposal highlighted the need for a better emergency security mechanism within the Threshold DAO. In emergency situations - the 2 day vote delay and the 10 day vote period in the StakerDAO is too long for a proper response to be executed which might result in the exploitation of our network. This developer multisig is intended to serve as a critical fallback security mechanism for the Threshold network.
The v2 DAO proposal calls for the creation of a 3-of-4 Emergency Security Developer multisig with two technical representatives appointed from both the Keep team and NuCypher team. This multisig holds the power to propose network changes immediately after a vulnerability is found only in emergency situations. These proposals can be immediately executed by the elected council.
The proposal was ambiguous as to whether the scope of the ESDM applied to application-level contracts or only to network-level
@Agoristen raised the concern that if the tBTC v2 contracts are subject to the ESDM, there’s a risk of malicious seizure of users’ BTC. Due to tBTC’s premise as a non-custodial, censorship-resistant, trust-minimized bridge this could compromise the primary raison d’être of tBTC.
The ensuing discussions across the forum, chat, and community calls made it clear that the mechanics of the ESDM required additional debate and a dedicated proposal, separate from the rest of the (otherwise uncontroversial) DAO v2 proposal. As a result, the ESDM aspect was removed and tabled for further discussion so that the rest of the DAO v2 proposal could proceed to a community snapshot.
To proceed with the discussion on emergency security fallbacks, let’s explicity distinguish between:
- Network-level emergency security mechanisms for DAO governance contracts, T staking contracts, NU/KEEP<>T vending machine contracts, token grant contracts, etc., and;
- Application-level emergency security mechanisms for tBTC v2 contracts, PRE contracts, random beacon contracts, etc.
For (1) network-level security, my baseline assumption is that there will be an ESDM since it’s not possible to safely upgrade a contract in a timely manner in public solely via a DAO proposal, as @tux pointed out in Discord. Whether the ESDM has the power to directly upgrade contracts or only to temporarily pause contracts while a formal DAO proposal is being voted on/approved needs further consideration.
For (2) application-level security, let’s start by assuming that, depending on the power of the network-level ESDM, each application may wish to impose more restrictive security mechanisms than what the network provides.
For example, tBTC may wish to somehow limit upgradeability such that taking control of BTC is impossible or opt-out entirely via immutable, non-ownable contracts (although this is unlikely as v2 is taking an incremental approach to product development).
I believe these are the network-level security questions that need to be answered prior to Threshold launching:
- Is there a satisfactory alternative to a network-level ESDM?
- Assuming there isn’t, should the ESDM be able to upgrade contracts directly or only temporarily pause contracts while the DAO approves a security fix? Are there potential security vulnerabilities where pausing is not sufficient?
- If the ESDM can only pause contracts, what are the parameters (timeline, etc.)?
- What is the composition of the ESDM (members, quorum, etc.)?
There are additional application-level security questions that need to be answered prior to tBTC v2 (and other applications) launching, which means we have additional time to consider them:
- How can we preserve the raison d’être of tBTC along with an incremental approach to product development post-launch and the ability to fix security vulnerabilities?
- Is there a way to implement an ESDM with limited powers (specifically, no ability to malicious take control of users’ BTC) while preserving the ability to fix potential security vulnerabilities?
- Does a limited ESDM simply mean removing the ability to directly upgrade contracts in favor of only temporarily pausing contracts while the DAO approves a security fix?
- If so, can we require applications to inherit network-level security after all (if we similarly decide on a pause-only ESDM at the network-level)?
I suspect we may uncover additional questions as the discussion evolves!