Background
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 lock()
and 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 DsChief
.
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 OsmMom
and 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:
-
DsChief
must 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
DsChief
to the newDsChief
- 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).
Migration Considerations
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.
Migration Steps
- Deploy the new
DsChief
. - Write and deploy a spell that switches the authority for all relevant contracts (the
Pause
, theMkrAuthority
, theOsmMom
, and theFlipperMom
) from the oldDsChief
to the newDsChief
. -
MKR holders vote the spell in as the
hat
. -
MKR is kept on the
hat
during the governance delay period. This ensures no other spells are scheduled before the oldDsChief
is disabled, either by flash loans or normal voting. - The spell is cast, switching authority to the new
DsChief
, and rendering the oldDsChief
powerless. -
MKR holders migrate to the new Chief and vote on a pre-designated activation
hat
(likely0x0
). By performing this step after the currentDsChief
has been disabled, the risk of a dangerous reduction in MKR on the activehat
is avoided. - Once sufficient MKR has been migrated, the new
DsChief
is activated and begins governing the system.
Timeline
- code review complete: November 13, 2020 (Friday the 13th)
-
kovan
spell complete: November 19, 2020 -
kovan
deploy ofDsChief 1.2
: November 20, 2020 -
kovan
testing: November 20, 2020 - governance poll: November 23, 2020
-
mainnet
spell complete: November 24, 2020 -
mainnet
executive ofDsChief 1.2
: November 27, 2020 - execution and migration to
DsChief 1.2
: November 27, 2020 -> December 3, 2020