The current Maker governance contract (
DsChief) design allows flash-borrowed MKR to be used to vote on proposals. This design led to a flash loan being used to pass the October 23, 2020 executive proposal. A number of short-term mitigations to limit the risk of flash loans in governance have already been introduced in the October 30, 2020 executive:
- The governance delay was increased to 72 hours giving additional time to remove maliciously-elected proposals.
- Governance has also remove the ability to instantly freeze oracles and disable liquidations. This prevents a flash loan attacker from damaging the system by triggering either of these mechanisms inappropriately.
In the medium-term the goal is to prevent the usage of flash loans in voting, while re-enabling the ability to instantaneously freeze oracles and disable liquidations, as these protections were added initially as defense mechanisms against other threats. This post presents an option for achieving these goals and outlines a transitional process to a new DsChief.
Recommended Solution: DsChief 1.2
By migrating the system to a new
DsChief, voting via a flash loan would be rendered impossible. Once in place, we would safely re-enable the ability of governance to vote on instantaneous oracle freezes and liquidation activation/deactivation. This upgrade is referred to as DsChief 1.2, as this would be the second upgrade to the original
DsChief design. Upgrading the
DsChief has a number of benefits.
Draft code changes: https://github.com/makerdao/ds-chief/pull/1
Flash loans cannot be used to pass proposals
On every call to
lock() MKR in the new chief, we would record the current block number, while at the same time ensuring that any corresponding call to
free() happens in a different block. The ability to call
free() in the same block is what allows for flash loans to be used with
DsChief, by preventing these calls from happening in the same block, we are in turn preventing flash loans from being used with
Raises the barrier for governance attacks
By preventing flash loans, governance mitigates governance attacks that require no capital or skin-in-the-game. While this does not prevent all types of governance attacks, it ensures certain economic barriers are in place that significantly increase the difficulty of such attacks.
Low-risk code changes
This fix is easy to understand at only 18 new lines of code in
DsChief. The low complexity and lack of new attack surface remove the need for time-consuming audits and increase confidence in this approach.
Governance attacks via flash loans are completely resolved prior to DssGov
Every time engineering teams are randomized onto emergency issues, it delays the rest of their roadmap. This delays collateral onboarding, liquidations 2.0, and the future
DssGov upgrade. There are a number of important governance features coming in the future
DssGov upgrade, and since flash loan prevention is one of the new features of
DssGov, any engineering time spent backporting that solution is duplicate work. Some of the other solutions we explored were mitigations that could still interrupt engineering timelines. Because this solution isn’t just a flash loan risk reduction, as past solutions were, but rather prevents flash loans entirely, we can be assured that engineering, and other, teams won’t be randomized onto other governance flash loan attack vectors.
The governance delay can be safely bypassed as needed
From time-to-time governance may require instant, albeit limited, access to change the Maker Protocol. This is achieved through emergency access modules that can bypass the GSM delay, called
Moms. Replacing the Chief preserves maximum flexibility for freezing subsets of oracles or triggering circuit breaker subsets. The existing
FlipperMom can be safely reenabled once the Chief is replaced, restoring the full emergency module functionality that had been disabled due to flash loan concerns. Further, this solution allows us to follow the same methodology in the future, creating new
Moms as needed.
Upgrading DsChief also comes with a number of concerns
All solutions have some drawbacks. Upgrading
DsChief is no exception and comes with the following risk considerations:
DsChiefmust include an activation threshold (a minimum amount of MKR must be staked to a particular address to allow the Chief to exercise authority over the system - this is to make the migration safer to accomplish).
- Maker governance must migrate from the current
DsChiefto the new
DsChief- this implies a period of time during which no governance action can be taken (due to the activation threshold in new Chief).
- Requires UI/UX work.
- MKR holders must take action (multiple TXs required to migrate).
Due to the aforementioned activation threshold, there will be a period of time during which governance actions cannot be taken at all (between casting the spell to switch to the new Chief and sufficient MKR migrating to it). Below, the exact sequence of steps is described, and possible risks of the migration (and their mitigations) are considered.
- Deploy the new
- Write and deploy a spell that switches the authority for all relevant contracts (the
OsmMom, and the
FlipperMom) from the old
DsChiefto the new
MKR holders vote the spell in as the
MKR is kept on the
hatduring the governance delay period. This ensures no other spells are scheduled before the old
DsChiefis disabled, either by flash loans or normal voting.
- The spell is cast, switching authority to the new
DsChief, and rendering the old
MKR holders migrate to the new Chief and vote on a pre-designated activation
0x0). By performing this step after the current
DsChiefhas been disabled, the risk of a dangerous reduction in MKR on the active
- Once sufficient MKR has been migrated, the new
DsChiefis activated and begins governing the system.
- code review complete: November 13, 2020 (Friday the 13th)
kovanspell complete: November 19, 2020
DsChief 1.2: November 20, 2020
kovantesting: November 20, 2020
- governance poll: November 23, 2020
mainnetspell complete: November 24, 2020
DsChief 1.2: November 27, 2020
- execution and migration to
DsChief 1.2: November 27, 2020 -> December 3, 2020