Threshold Network-Level Emergency Security Developer Multisig Proposal

This proposal is the next step in the defining the Threshold Emergency Security Developer Multisig (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.

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, as it's not feasible to responsibly fix an undisclosed emergency contract vulnerability in public or restrained by the 10 day DAO vote period.

Other contracts: There will be no relationship between the Threshold ESDM and the following contracts:

• 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: This contract does not need any ESDM mechanics. Nothing in the contract needs to be pauseable and there are no upgrades.
• 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.

Vote Structure:

The options are: 1 – Yes, I support the ESDM proposal 2 – No, I don't support the ESDM proposal

We kindly request that if you vote against the ESDM in this Snapshot, that you might drop a note in Discord #governance channel or on the forum – explaining your reasoning – such that our communities can work together to move forward based on this feedback. You can find a link to the discussion here.