MIP91 - Defender contract against governance attacks

--- tags: Research --- # MIP91 - Defender contract against governance attacks ## Preamble ``` MIP#: 91 Title: Defender contract to protect MakerDAO from governance attacks Author(s): @astronautthis Contributors: @LongForWisdom, @prose11, @Patrick_J Tags: emergency, governance, process, technical, smart-contracts, pending-implementation Type: General Status: RFC Date Proposed: 2022-10-26 Date Ratified: Contract address: Dependencies: ``` ## References 1. [Emergency Shutdown](https://docs.makerdao.com/smart-contract-modules/shutdown) 2. [GSM Pause Delay](https://makerdao.world/en/learn/governance/param-gsm-pause-delay/) 3. [Executive Vote](https://makerdao.world/en/learn/governance/how-voting-works/#executive-votes) ## Sentence Summary This MIP proposes a smart contract that allows a minority of MKR holders to delay executives during an attack where a malicious entity may be in control of the hat. ## Paragraph Summary The attack considered here is a governance attack where an entity has access to enough MKR to pass one or more potentially malicious executive spells. This MIP proposes a contract called `dss-defender` that a minority of MKR holders may activate to delay malicious executives from taking effect without shutting down the protocol. In order of preference, Maker would have the following responses to a governance attack: 1. Recapture the hat and pass a cancelling executive. 2. Activate `dss-defender`. 3. Trigger the Emergency Shutdown Module (ESM). ## Motivation Consider the situation where a malicious entity (including possible malicious actors within the Maker community) has access to enough MKR to pass executive spells. Given the chaotic environment during such an attack with the potential for trusted entities like Protocol Engineering or GovAlpha to turn malicious, it may be unreasonable to expect honest MKR holders to be able to communicate and coordinate quickly enough to defend the protocol. In particular, it may not be clear if the protocol is genuinely under attack or if there is simply misinformation. The following issues are likely with the current ESM-based defence: 1. Honest MKR holders only have the GSM Pause Delay period (48 hours at the time of writing) to trigger the ESM, a decision that involves burning their MKR. This is difficult to commit to if information about the attack is unclear. 2. It may be the case that large MKR holders use custodial solutions that would make it difficult to move their MKR to trigger the ESM or try and regain the hat within the GSM Pause Delay period. 3. The act of shutting down the protocol is an extreme step that negatively impacts DAI holders and the wider crypto ecosystem. The only immediate requirement is to block malicious executives while regaining control of governance, not to shut down the entire protocol. The ideal defence in the face of such an attack should be to prevent the malicious executives from passing so MKR holders can buy time to understand the situation, try to recapture the hat, and decide whether it is necessary to trigger the ESM. The key is to allow a minority of MKR holders to be able to do this without a severe financial penalty but also ensure that this does not become a tactic to stall/overrule regular governance actions. This will be done using a proposed contract called `dss-defender`. ## Component Summary **MIP91c1: Parameters and deployment** Defines the parameters of `dss-defender`, the governance process to set them, and deploying an instance. **MIP91c2: Core logic** Defines the core logic of an instance of `dss-defender` once activated. **MIP91c3: Post-activation permissions and events** Defines what actions are permitted after an instance of `dss-defender` is activated. **MIP91c4: Deploying a new instance** Defines how to deploy a new instance of `dss-defender` after a potential attack. **MIP91c5: Preliminary Work Packages** Defines the next phases of work required by various Core Units. **MIP91c6: Technical Implementation** Defines the smart contract code of `dss-defender`, test cases, and formal verifcation/audits. **MIP91c7: Initialization** Defines the governance process to approve the first instance of `dss-defender`. ## Specification / Proposal Details ### MIP91c1: Parameters and Deployment `dss-defender` has three parameters that can be modified by Governance. These are: 1. `threshold amount`: This is the amount of MKR that must be deposited into an instance of `dss-defender` to activate it. 2. `cancel-spells duration`: This is the duration for which an instance of `dss-defender` can cancel executive spells using the mechanism detailed in MIP91c2. 3. `lockup duration`: This is the duration for which MKR deposited to an instance of `dss-defender` is locked by default. This parameter should be significantly larger than the `cancel-spells` duration to prevent a minority of MKR holders from stalling governance. The lockup period can be overriden by two mechanisms detailed in MIP91c3. Risk-001 should recommend initial choices and changes to these parameters. They may be changed via weekly governance polls or emergency/weekly executive votes. An instance of `dss-defender` is then deployed with these parameters. This disables the core logic described in MIP91c2 of any previously deployed instance. ### MIP91c2: Core Logic MKR may only be deposited into an instance of `dss-defender` by MKR holders. Delegates cannot deposit delegated MKR into an instance of `dss-defender`. Honest MKR holders should only deposit MKR if they suspect one or more malicious executives have been passed and that the hat cannot be recaptured from the attacker by the end of the GSM Pause Delay. If there is more MKR than the `threshold amount` deposited into an instance of `dss-defender`, a permissionless parameterized `cancel function` on the contract is enabled. The `cancel function` allows anyone to cancel any executive waiting during the GSM Pause Delay. The `cancel function` would be available for the `cancel-spells duration` from the moment the `threshold amount` is exceeded. For each instance of `dss-defender`, this mechanism can only be triggered once. To use the `cancel function` after the `cancel-spells duration` is over, MKR holders must initialize a new instance `dss-defender` via an executive vote. ### MIP91c3: Post-activation Permissions and Events MKR deposited into an instance of `dss-defender` will be locked in the contract for the `lockup duration` from the moment it is deposited except for two cases, namely: 1. A majority of MKR holders (including depositors) pass an executive vote to allow early withdrawals from an instance of `dss-defender`. 2. The depositors move the locked-up MKR into the ESM, at which point it will be immediately burned. In addition to activating the `cancel function`, every instance of `dss-defender` moves all MKR deposited into it to support a default executive spell that 1. Enables an early release of locked-up MKR in that instance. 2. Creates a new instance of `dss-defender` with the same parameters as the current instance. 3. Can only be `cast` after the `cancel-spells duration` is over. This point ensures that if enough MKR supports the default executive before the `cancel-spells duration` is over, it does not get `cast` immediately and get cancelled by the attacker. Regardless of other actions, after the `lockup duration` is over, MKR in a given instance of `dss-defender` can be withdrawn by depositors. ### MIP91c4: Deploying a New Instance It should be ensured that there is at most one instance of `dss-defender` available at any time. The deployment of a new instance is done via an Executive Vote and is subject to the GSM Pause Delay. After an instance of `dss-defender` is activated, there are two expected routes to deploy a new instance: 1. If MKR holders believe that a genuine attack was thwarted by an instance of `dss-defender`, then they should take control of the hat by backing the default executive of that instance described in MIP91c3. This executive will pass after the `cancel-spells` duration and restore the system to the pre-attack state. A new instance will be active and all deposited MKR will have been immediately returned to owners. 2. If MKR holders believe that an instance of `dss-defender` was triggered unnecessarily or in order to stall legitimate governance, then they may choose to deploy a new instance of `dss-defender` and enforce the full `lockup duration` of the previous instance. This would prevent depositors from participating in governance for the `lockup duration`, except for their ability to trigger the ESM. ### MIP91c5: Preliminary Work Packages The following work packages are required before `dss-defender` can be implemented. Should MIP91c5A or MIP91c5B not be complete or highlight issues with the proposal, this MIP will not be implemented. #### MIP91c5A: Formal Modelling Protocol Engineering CU to formally model `dss-defender` and ensure that the protocol is not opened up to additional attack vectors or griefing attacks. Findings to be linked here. #### MIP91c5B: Parameter Choices Risk CU to investigate appropriate choices for `threshold amount`, `cancel-spells duration`, and `lockup duration`, thereby balancing governance security and governance efficiency. Findings to be linked here. ### MIP91c6: Technical Implementation Pending a positive outcome of MIP91c5A and MIP91c5B, Protocol Engineering to design a smart contract implementation of `dss-defender`. #### MIP91c6A: Proposed Code To be added/linked here. #### MIP91c6B: Test Cases To be added/linked here. #### MIP91c6A: Formal verification/Audit Information To be added/linked here. ### MIP91c7: Initialization After MIP91c5 is complete, an on-chain MIP poll will propose the initialization of the first instance of `dss-defender`. -------- *This section will be added as a separate post below the MIP.* Here, I detail some of the benefits and downsides of this proposal. There are also some clarifying examples. ### Benefits Under normal circumstances, there should be little to no MKR deposited into `dss-defender`. The ability to use this as a stall tactic against normal governance processes is mitigated by the `lockup duration` and the fact that an executive is delayed only for the `cancel-spells duration`. During a governance attack, if MKR in `dss-defender` exceeds the `threshold amount`, MKR holders get more time to organize and possibly trigger the ESM. Since there is no penalty besides losing access to their MKR for the `lockup duration`, MKR holders may be more willing to take the first step to defend the protocol. In the event that the hat cannot be taken back after the `cancel-spells duration`, it becomes clear to all honest MKR holders that the ESM must be activated. ### Downsides A malicious minority could block a governance patch fixing some vulnerability using `dss-defender` to buy themselves more time. It is unclear how high this risk is and whether it is sufficiently mitigated by [MIP15](https://mips.makerdao.com/mips/details/MIP15). Delegates are unable to use `dss-defender`. One may wonder if there is a way to allow delegates to interact with `dss-defender` albeit with different penalties instead of regular holders. Unfortunately, the `lockup duration` seems incompatible with the principle of liquid delegation. ### Example Scenarios This section has some examples explaining how various scenarios may play out. This is meant to be illustrative, not exhaustive. We choose some arbitrary parameters here. The `threshold amount` is set to 50,000 MKR, the `cancel-spells duration` is one week and the `lockup duration` is one month. #### Genuine attack A malicious entity gains control of the hat and starts passing executives to steal collateral. It becomes clear within 24 hours of the 48-hour GSM Pause Delay period that the hat cannot be regained and the malicious executives cannot be cancelled. Large MKR holders such as VCs need more time to move their MKR from custodial solutions to help regain the hat. 1. MKR holders start depositing their MKR into `dss-defender` until it hits 50,000 MKR. 2. The cancellation of all executives begins and the protocol is locked into its current state for one week. 3. Large MKR holders are now able to mobilize their MKR to regain control of the hat. They join forces with the MKR already in `dss-defender` by backing the default executive that resets the protocol to the pre-attack state and returns locked up MKR to the owners early. 4. The default executive is ready but can only be passed after `dss-defender` stops cancelling spells. All other malicious executives that have been passed and are in the GSM Pause Delay period get cancelled. 5. After one week, the protocol returns to its pre-attack state. #### Genuine attack - alternate ending This is the same as the previous scenario except that honest MKR holders do not succeed in retaking the hat. A malicious entity gains control of the hat and starts passing executives to steal collateral. It becomes clear within 24 hours of the 48-hour GSM Pause Delay period that the hat cannot be regained and the malicious executives cannot be cancelled. Large MKR holders such as VCs cannot move their MKR from custodial solutions to help regain the hat within the `cancel-spells duration`. 1. MKR holders start depositing their MKR into `dss-defender` until it hits 50,000 MKR. 2. The cancellation of all executives begins and the protocol is locked into its current state for one week. 3. After the one-week period is over, the attacker still holds the hat and starts passing malicious executives again. This is subject to the GSM Pause Delay that starts the moment the one-week period is over. 4. All honest MKR holders, including those who deposited their MKR into `dss-defender` move their MKR to the ESM. 5. The ESM threshold is reached and the protocol is shut down without loss of collateral. #### False alarm A minority of MKR holders believe a recently passed executive is an attack on Maker. They collectively deposit enough MKR to reach the `dss-defender` threshold. 1. `dss-defender` is now able to cancel spells for one week. 2. During this one-week period, the remaining MKR holders examine the situation more closely and conclude that the executive is not malicious. 3. The executive is passed again after the one-week period ends and is now in the GSM Pause Delay period. 4. MKR holders conclude that although the executive was not malicious, the depositors acted in good faith and return their MKR early via the default executive vote and reset the protocol to the pre-attack state. #### Disgruntled minority attack A minority of MKR holders use `dss-defender` to delay an executive they disagree with. The events are identical to the false alarm scenario except for Step 4. 1. `dss-defender` is now able to cancel spells for one week. 2. During this one-week period, the remaining MKR holders examine the situation more closely and conclude that the executive is not malicious. 3. The executive is passed again after the one-week period ends and is now in the GSM Pause Delay period. 4. Remaining MKR holders conclude that the depositors tried to stall governance using `dss-defender`. The depositors must wait one month before they can participate in governance again. The scenarios above are some of the most likely possibilities to consider when implementing `dss-defender`. The `threshold amount`, `cancel-spells duration`, and `lockup duration` should be chosen with these possibilities in mind.