MIP - Defender contract to respond to governance attacks

--- tags: Research --- # MIP - Defender contract to respond to governance attacks ## Preamble ``` MIP#: <# to be assigned> Title: Defender contract to respond to governance attacks Author(s): @astronautthis Contributors: @LongForWisdom @prose11 @Patrick_J Tags: emergency, governance, process, technical, smart-contracts Type: General Status: RFC Date Proposed: 2022-10-20 Date Ratified: Dependencies: ``` ## References - [HackMD description with additional examples](https://hackmd.io/Grfx1w41S8mOjwYtkehqRw). ## 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 control the hat. ## Paragraph Summary The attack considered here is a governance attack where a malicious entity has access to enough MKR to pass one or more malicious executive spells. The primary defence against such an attack would be for honest MKR holders to retake the hat and cancel the malicious executive(s) within the GSM Pause Delay period. If that fails, the final defence in this scenario is the ESM-based defence, where a minority of MKR holders trigger the Emergency Shutdown Module. This MIP proposes an intermediate step, dss-defender, that a minority of MKR holders may activate but does not shut down the protocol. ## 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 PE 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 which involves burning their MKR. This is difficult to commit to if information about the attack is unclear. 2. It is well known that large MKR holders use custodial solutions that would make it impossible 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 inconveniences 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. ## Specification / Proposal Details Consider a contract called ``dss-defender``. This has three parameters - the `threshold amount`, the `cancel-spells duration`, and the `lockup duration`. MKR may only be deposited into `dss-defender` by MKR holders. Delegates cannot deposit MKR into `dss-defender`. Honest MKR holders should only deposit MKR into this contract if they suspect malicious executive(s) have been passed and that the hat cannot be recaptured from the attacker. Their MKR will be locked into this contract for the `lockup duration` from the moment it is deposited except for two cases, namely: 1. A majority of MKR holders (including depositors) vote for an early release. 2. The depositors wish to move the locked up MKR into the ESM, at which point it will be burned. If there is more MKR than the `threshold amount` deposited into `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. This mechanism can only be triggered once. To use this `cancel function` after the `cancel-spells duration` is over, MKR holders must reinitialize `dss-defender` through an executive vote. In addition to activating the `cancel function`, `dss-defender` moves all MKR deposited into it to support an executive that enables an early release of locked up MKR in `dss-defender` and reinitialize `dss-defender`. If a genuine attack was thwarted, then all remaining honest MKR holders should take control of the hat by backing this executive, which will pass after the `cancel-spells period`. This restores the system to the pre-attack state and returns deposited MKR. Regardless of other actions, after the `lockup duration` is over, MKR in `dss-defender` can be withdrawn by depositors. At any point, including during the `lockup duration`, MKR tokens in `dss-defender` can be moved to the ESM by depositors. ## Component Summary This proposal should be implemented in the following order. ### MIPxxc1: Phase 1: Formal modelling and risk verification Protocol Engineering CU to formally model `dss-defender` and ensure that the protocol is not opened up to additional attack vectors or griefing attacks. In parallel, Risk CU to recommend appropriate choices for `threshold amount`, `cancel-spells duration` and `lockup duration` thereby balancing governance security and governance efficiency. Should either of the above verifications fail or highlight issues with the proposal, this MIP will not move forward to the next phase. ### MIPxxc2: Phase 2: Smart contract implementation requirements Pending a positive outcome of verifications, Protocol Engineering CU to investigate smart contract implementation of `dss-defender`.