[Urgent] Flash Loans and securing the Maker Protocol

Legacy Updates
, , ,
1

On the 26th October, the Smart Contracts Domain Team detected voting behaviour irregularities with respect to: Increase the Surplus Buffer, Oracle Whitelisting - October 23, 2020 proposal. It has since been confirmed that a flash loan was used to pass the October 23rd proposal in the following manner:

  1. Oct 26, 2020, 17:37:17 UTC a single transaction was executed
    a. WETH was borrowed from dYdX with a $20m flash loan (50k ETH)
    b. This was deposited on AAVE, and used to borrow $7m MKR (13k MKR)
    c. The MKR was locked in governance, chief.lock()
    d. Voted on the proposal with chief.vote()
    e. Made the hat with called chief.lift()
    f. Then freed with chief.free()
    g. The spell with the hat was scheduled with spell.schedule()
    h. The MKR was unlocked and returned to AAVE and dYdX
  2. Finally, after the GSM delay of 12 hours (Oct 27, 2020, 05:37 UTC), the spell was then executed with spell.cast()

The Maker Foundation has been in contact with the BProtocol team, and are aware that they were responsible for the flash loan. BProtocol has been fully transparent in communicating their actions once the Foundation became aware of the voting irregularities.

Their actions are a practical example for the community that flash loans can and may impact system governance and highlight that MKR market liquidity needs to be actively monitored.

The DAO also needs to assess its ability to react in the event a more contentious vote is pushed through. The fact that the proposal in question was directly related to BProtocol being whitelisted on the ETHUSD Medianizer and OSM oracles raises some concerns as to how/if flash loans should be accepted in such circumstances.

In addition to this issue, last week was the first time in which a malicious governance attack using flash-loans has been theoretically possible (the available MKR liquidity exceeded the value of MKR on the hat.)

While the GSM pause delay does allow governance 12 hours (currently) to react to a malicious proposal, it is still an open question as to whether MKR Holders would be able to react in time. Additionally, the Liquidation Circuit Breaker (FlipperMom) and the Oracle Freeze Module (OsmMom) are both modifiable outside of the GSM Pause Delay.

In light of both the flash loan on the 23rd and the reduced amount of MKR on the hat, both the Smart Contracts Domain Team and the Governance Facilitator feel that the risk of malicious governance action has become unacceptably high.

There are two primary issues that have been identified:

1. The risk of malicious governance action using flash loans has become unacceptably high.
2. Flash loans can be used to pass controversial governance proposals.

The rest of this post will deal solely with the first issue, with the second to be addressed once the Maker Protocol has been further secured against malicious governance proposals.

At time of writing, there is MKR liquidity available on multiple platforms that can be used by flash loan attacks:

  • 42,649 MKR in Balancer
  • 15,170 MKR in AAVE
  • 5,626 MKR in Uniswap

This comes to a total of 63,445 MKR that is accessible using flash loans.

Given that the current hat proposal has ~79k MKR, there is no immediate risk of governance attack. However, there is risk when new executive proposals are submitted.

In light of this issue the Governance Facilitator and the MakerDAO Smart Contracts Domain team will take the following actions.

Actions

Prepare executive spell to minimize risk

The MakerDAO Smart Contracts Domain Team will prepare an executive spell that if ratified will take the following actions:

  • The GSM pause delay will be increased to 72 hours.
  • The Oracle Freeze Module (OsmMom) will be deauthorized.
  • The Liquidations Circuit Breaker (FlipperMom) will be deauthorized.

We are aware that disabling the Oracle Freeze Module and the Liquidations Circuit Breaker increases risk in other areas. We feel that the Oracle and Liquidation risks are less than that of governance attack especially given the additional lightfeeds and box parameter.

72 hours was chosen given that it stretches across at least one working day, regardless of the timing on the governance attack. This gives Governance more time to secure the hat, and domain teams time to prepare an action to cancel the plotted spells.

This executive spell will not immediately be put on-chain.

Gather more MKR on the hat proposal

We feel that additional MKR is required on the hat in order to ensure safety while MKR transitions from one proposal to another.

The Governance Facilitator will provide additional updates and next steps once either of the following conditions has been met.

  • The MKR on the hat exceeds 100,000 MKR
  • One week has passed.

100k MKR was chosen because it exceeds the 63k currently available liquidity, and the new governance portal has a feature that allows voting on multiple proposals at once which should mitigate the risk of the hat proposal decreasing below 63k during the transition.

Signalling around Governance Attack Response

The Governance Facilitator will post a signal request that will aim to confirm the following sentiment to all MKR Holders:

“In the event of a malicious governance attack that leads to redeployment of the Maker Protocol prior to the introduction of flash loan guards into the governance process, the community and domain teams should do everything possible to burn the MKR involved in the attack, regardless of whether the owner was directly involved in the attack.”

Edit: [Signal Request] Should the Maker Community burn attacking borrowed MKR in the event of a governance attack leading to protocol redeployment?

Reaching out to large MKR Holders

The Smart Contracts Domain Team, and the Governance Facilitator will attempt to contact large MKR Holders with MKR on Aave, Balancer and Uniswap with the aim of convincing them to remove MKR from these platforms until flash loan guards are in place and to add their MKR to the current hat and vote in the coming executive.

The executive containing YFI and BAL collateral onboarding will be delayed

The Smart Contracts domain team was aiming to have these complete this week, however the flash loan issue has taken priority for the time being.

The Smart Contracts Domain Team will explore options to mitigate the flash loan risk prior to the DssGov upgrade

Given the potential severity of flash loan related attacks, the Smart Contracts Domain Team feels that it is wiser to resolve the vulnerability from flash loans sooner than would be possible if they waited for DssGov.

38 Likes
2

I’d like to take this opportunity to encourage all MKR Holders to vote on the current hat to help secure the protocol.

I’d also love to hear feedback on the above response. This is the current plan, but it isn’t set in stone and can be modified if the community presents solid arguments for why this is unsuitable.

Thanks all.

7 Likes
4

Curious. Might it also be possible to introduce a delay from the time MKR is deposited into the Executive voting construct until when the owner could vote. I would think that if that delay was 24 hours (or even a week, if needed), the risks associated with flash loans would be hedged. Thoughts?

6 Likes
5

Interesting, flash loans enables people to push through executives without the capital needed (with current model).

Though one thing to note, Balancer costs slightly more than a normal flash loan attack at a 2% fee.

1 Like
6

Even just a single block delay between locking and freeing MKR in the Chief would be sufficient. This is one of the solutions we’re researching (already have the code under review, in fact). The downside is that you have to migrate from the old Chief to the new Chief. We’d add an activation threshold to the new Chief to avoid being vulnerable to voting by small amounts of MKR during the transition, but then there would also be a period of time during which no governance actions could be taken (an unpredictable one, determined by how long it takes MKR holders to migrate in sufficient token quantity).

15 Likes
7

Signal Request is now live and can be found here: Should the Maker Community burn attacking borrowed MKR in the event of a governance attack leading to protocol redeployment?

2 Likes
8

Personally speaking, we might as well make sure we are making MKR borrowing for executives “expensive” by making the time longer than one block… On the extreme minimum, one day (in my eyes) all the way to a week or longer.

Anyone that would be borrowing MKR to make a decision wouldnt want to take pricing risk of MKR. By being force to hold in executive voting construct for a period of time, we make it less economically attractive to have an attack vector to use borrowed MKR.

Let’s get started earlier than later!

3 Likes
9

I’d like to highlight this thread regarding DssGov again: MIP26: DssGov - Governance Contract Redesign

Many of the solutions people are suggesting have either been covered in that MIP, or in the responses. Please do give it a read and express your support for the functionality you want to see in the next major upgrade.

5 Likes
10

What does this mean, practically speaking, for Vault owners?

4 Likes
11

Right, you could make the locking period longer to discourage the use of ordinary borrowed MKR; we’ve discussed that as well. You walk a fine line there between securing the system and making voting less attractive due to illiquidity risk, which might decrease participation. From a practical perspective, it’s not clear how long that locking period would need to be to be effective, or at what point you’d actually discourage voting. Right now we’re focused on addressing the highest-priority issue, flash lending. With the DssGov upgrade coming in a couple months, it may make sense to limit the scope of what we’re trying to solve here.

2 Likes
12

100% agreed. The rest is an optimization. I do however believe that most folks that vote leave their MKR in the executive voting contract, with a small minority moving in and out.

From that lens, I tend to agree.

1 Like
13

It means that Maker Governance will not be able to prevent liquidations in the event of significant downward market movement, and it means that Maker Governance will not be able to freeze the oracle prices in the event of an oracle attack.

On the flip side, someone performing a flash loan governance attack will not be able to:

  • Freeze the oracles.
  • Prevent Liquidations.

I’m not sure that it really means much different for vault holders, they weren’t able to rely on governance using these systems anyway.

3 Likes
14

I’ll add on to LFW’s points that with the box parameter that limits the amount of DAI needed to cover debt+fees of active auctions by preventing liquidations after a certain point, the system has additional resilience to price crashes/oracles attacks that was not present when the instant access modules were originally conceived.

5 Likes
15

There is a relatively large amount of MKR on Balancer. I believe on primary reason for this is the ability to earn BAL rewards for providing liquidity. According to pools.vision, the largest MKR pool is earning roughly ~17% APR in BAL rewards.

Balancer uses a mechanism called capFactor to limit the total dollar value of liquidity for any one token that is eligible for rewards (this was introduced to guard against manipulation of the distribution). We could potentially ask Balancer community to reduce MKR to a lower capFactor for the time being until we have guards in place against flash loans. This will reduce incentives to provide MKR liquidity.

If this sounds like a good idea to pursue in the short term, I’m happy to reach out to Balancer forum and team to see how this can be accomplished.

6 Likes
16

great idea… and wonderful initiative! please !! It cannot hurt …

1 Like
17

Are we increasing the OSM GSM delay to 72 hours? It should be the responsibility of ALL MKR holders that a malicious proposal that passes doesn’t get executed.

Flash loan attacks to pass a proposal have a cost. In this case, they even took steps to avoid paying the 0.09% AAVE flash loan fee. Balancer would have a 2% flash loan fee.

Well, some people might love to reduce the capFactor, you also might have trouble raising the capFactor back again. (Last capFactor raise for MKR was quite contentious and passed with 55.45%)

3 Likes
18

I don’t think so. 72 hour delayed price data seems not great. Perhaps I’m misunderstanding you.

The 2% there comes from trading fees on the balancer pools?

As I mentioned in one of my replies, this isn’t necessarily a fixed plan. Do you feel that we should be taking a different response, or that we’re overestimating the risk?

19

After the immediate remediation is taken care of (the freezes and such), I would propose a simple way to prevent future governance manipulation using flash loans would be to change the requirements on chief.vote() to check the MKR locked in the preceding block in chief.lock(). That way someone can’t borrow, lock and vote in the same block. If I’m not mistaken that’s how Aragon safeguards as well

Edit: Grammer

1 Like
20

This is one path of exploration. We’ve made this change in the upcoming DssGov (MIP26: DssGov - Governance Contract Redesign) and are considering pulling this feature into a 1.1 upgrade on the current DsChief design. There are, however, other possible remediations up for consideration and we are carefully weighing all the risks.

5 Likes