This proposal is co-created by myself, David Nuñez and Piotr Dyraga.
Introduction:
Threshold Emergency Security Developer Multisig (ESDM) mechanics were removed from the Threshold DAO proposal so that our community could move forward with snapshots on the rest of the uncontroversial proposal.
This proposal is the next step in the defining Threshold ESDM mechanics. It focuses on network-level mechanics because they are required before the merge contracts are deployed. Per-application ESDM mechanics are more complex and are not required for merge contract deployment. Thus - to stick as close as possible to the merge timeline, per-application mechanics will be proposed, defined and discussed in more detail at a later time.
Why Threshold ESDM?:
Threshold needs an ESDM to mitigate protocol risk. Some form of an ESDM is relatively standard across other relevant protocols in our industry. Each one is designed to meet the needs of the protocol it helps protect.
We must collectively agree on and implement fall back security mechanisms to develop a responsible protocol.
Further reference -
- Emergency Response Team in the current NuCypher DAO
- Pause Guardian in Compound Governance
- Emergency DAO multisig for Curve
Composition:
The Threshold ESDM will be 3-of-4 composed of two members of the Keep developer team and two members of the NuCypher developer team. At least one developer from each team must agree to an action impacting Threshold network-level contracts before the action is conducted. The composition of the ESDM should start with a smaller set (and then potentially expand) because individuals need to rapidly sign transactions with a secure, air-gapped setup. Coordinating this with a smaller group reduces overhead, allowing for more effective execution of tasks in situations where response time deeply matters.
This proposal designates the following individuals for our Threshold ESDM:
- Piotr Dyraga, Keep Network
- Kuba Nowakowski, Keep Network
- MacLane Wilkison, NuCypher
- David Nuñez, NuCypher
The TokenHolder DAO is responsible for votes on replacing or adding new members to the Threshold ESDM in the future if the need arises.
Threshold Network-Level ESDM:
Threshold network-level ESDM mechanics are defined as the relationship between the Threshold ESDM and network-level contracts. This includes the T staking contract (plus Keep stake), vending machine contracts, T token contract and DAO contracts.
This proposal describes ESDM mechanics for each of these network-level contracts (even in absence of a relationship) individually to provide clarity, completeness and transparency.
Threshold Staking Contract:
The Threshold staking contract was designed with multiple emergency provisions. There is a role named panic button that is set on a per application level. The panic button role can call pause. Pause is an emergency, temporary measure that:
- Pauses the application from slashing stakers
- Blocks stakers from increasing or decreasing their stake authorization for the application
The Threshold ESDM should retain panic button power for each application. Panic button does not give the Threshold ESDM direct power over tBTC. It only impacts slashing and staking authorization.
Applications are unpaused by the contract owner which is eventually the DAO. The owner of the staking contract can also disable apps.
Regular staking contract upgrades are executed by the Staker DAO. However, it is proposed that the Threshold ESDM also intermittently retains the ability to upgrade the Threshold staking contract only in emergency situations. Thus, initially - there will be two simultaneously existing upgrade paths. Why? It is not feasible to responsibly fix an undisclosed emergency contract vulnerability in public or restrained by the 10 day DAO vote period. In the future, executing upgradability of the Threshold staking contract can solely be owned by the Staker DAO. This transfer of responsibility can occur via a DAO vote. As of now, it is not valuable to put an arbitrary timeline on when it happens considering the lack of insight to future events.
Finally, the Keep stake (adapter contract) does not need ESDM mechanics. The owner of the contract can add operator-stake owner pairs to those already snapshotted from legacy KEEP staking contract. We do not anticipate this being a need but have included it just in case.
Vending Machine Contracts:
There will be no relationship between the Threshold ESDM and the KEEP and NU vending machine contracts. Once the contracts are deployed there are no roles, no ability to pause functionality or any need to upgrade.
T Token Contract:
The T Token contract does not need any ESDM mechanics. Nothing in the contract needs to be pauseable and there are no upgrades.
The T contract only has two restricted operations: token minting and misfund recovery. The TokenHolder DAO is the sole authorized entity for both operations and the Threshold ESDM has no control over it.
Threshold DAO Contracts:
The Threshold DAO contracts do not need ESDM mechanics. No pause functionality. Upgrades are executed by the TokenHolder DAO. Defense was baked into the DAO design with temp check moderation, proposal threshold, quorum and council vetos.
Conclusion:
Insight, questions, comments and improvements on this proposal from the Threshold community are highly appreciated.
If no significant pushback surfaces during the discussion then this proposal will reach both a Keep snapshot and NuCypher snapshot.