[Urgent] Flash Loans and securing the Maker Protocol

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.


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.


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

1 Like

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%)


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?

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

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.


Newbie trying to understand what is going on.

The Maker Foundation has been in contact with the BProtocol team, and are aware that they were responsible for the flash loan.

Is it true to say that B.Protocal team is the one using flash loan to pass the executive vote, hence whitelisted their price oracle?

If so, why would they do that? Given that an executive vote will usually pass sooner or later? That sounds a bit of aggressiveness involved, and a compromise in credibility that someone will do everything to achieve the goal

I also have a question, to pass an executive vote, isn’t that MKR needs to be locked and in support to the vote. How can it be done using flash loan?


@chonghe There was also some time pressure for last Friday’s executive. Needed to be passed by Monday, before the Monthly MIPs bundles executive.


This is Yaron, the founder of B.Protocol.
Idk how much our side is relevant to the discussion, but let me put it here to have some context for future generations…

We meant no harm, and no harm was made.
Our view is that MakerDAO was never under real threat, and flashloans are only a future (theoretical) threat.

B.Protocol is built on top of Maker, and makes it stabler by bringing committed Keepers, who share proceeds with users.
Showcasing the potential vote vulnerability was aimed to trigger an internal technical discussion on ways to improve it, and we did not anticipate the community will view it as an immediate threat.

MakerDAO were very helpful to us during our integration process, and in retrospect we regret not disclosing this issue to them in a more responsible manner, which would have eliminated the sense of urgency.


A technical comment, the more votes in the current hat makes it more secure, but on the other hand makes it harder to mitigate a flash loan vote attack, as it will be harder to vote for an undo hat, in a 12 hour period.


Thanks @LongForWisdom and domain temas, for reacting quickly to the danger. I have voted in the other poll.

This said, I would like to complain about the use of “URGENT” and “EMERGENCY” decisions.

In this specific case, the issue was far from unpredictable. It was always there and pointed by many people. I myself (with all my limits) have mentioned it here:

more than 2 months ago.

Why are we waiting the attack to happen (fortunately it was the BProtocol team) to start taking counter-measures?

I understand that the attack has become theoretically viable only very recently, but it was clear months ago that this would happen at a certain point.

Similarly, it is easy to predict that MKR-borrowing will become an issue eventually, even without recurring to flash loans. Flash loans just make it cheap and easy, today.

We should now start discussing deeply about how to reorganise the tokenomics of MKR to incentivise virtuous behaviour (voting, participation, etc).

It’s not acceptable that only ~8% of existing MKR are used for voting, given that MKR is a Governance Token.


Hi @iammeeoh def agree with you about predicability, however we still have muscle constrains and the prioritization was/is on the peg & collateral onboarding, as this there are other contigent risks but we can´t solve them all at the same time, this was a contigent risk and has taken priority after it happened. Definitely agree we should review the token economics complementary to the proposed course of action (on which I also do agree and thank for the flash quick response from everyone involved). People should be free to use maker however they please and we should work on allinging the incentives in order to have the desired outcome.


Agree, this should have been fixed before.

Nonetheless, if “governance attack” risk is bigger than “oracle and liquidation risks” than, this lesson was highly less expensive than $30M black thursday

Can’t we also use flash loans to defend an attack too? Flash loans seem a bit stronger for veto’s since there’s no GSM delay for them.


This is an interesting idea. A defensive bot which will cancel any spell it can with all available flash loan liquidity. This should protect against us getting caught off guard.

One cool thing about this strategy is that anyone can run it.


@yaronvel just to be clear. The first issue mentioned takes priority due to its severity. I’ll start getting to the second on Monday. I strongly disagree with your statement that no harm was done.

A fundamental assumption within the Maker Protocol is that ‘If you do not own MKR, you are not supposed to be able to influence governance decisions.’

You do not own 13,000 MKR and you were not supposed to influence this governance decision.

Just because the governance contract makes it possible to do something doesn’t mean that you should do it.

I believe that the claim that this was done to showcase a vulnerability is a rationalization of a decision that you made for entirely different reasons. The flash loan was not executed until the point at which it seemed like the vote was going to ‘fail’ (be replaced by the monthly MIPs vote). Showcasing a vulnerability was possible on any other governance vote, there has been 13k MKR available on Aave for months. Choosing to showcase it on your own proposal is a terrible idea, for this exact reason (it throws doubt on the outcome and leads to beliefs like this one.)

I believe the most likely explanation for why you waited until the last minute is that you knew what you were doing was sketchy, but you felt that the Maker Governance process was less important than you getting access to the Maker Oracles and launching your platform.

Ultimately it will be up to the community and actual MKR Holders to decide what (if any) response there should be, but that discussion will take place. Playing this off as no big deal is not helping your case (at least when it comes to me.)


If MKR tokens are placed on the Maker platform, will it cause less damage than AAVE?

Should we compare the advantages and disadvantages of each.

I think this is very importante, it’s needed some way to incentivise voting, if not there will always be the same votes or less than today, of course we know that there are MKR whales, but incentivise for sure will bring more new and unique voters, and that’s what we want.


I agree that there should be some mechanism to attract more value-added ideation and engagement in the voting process. We do not have governance by the majority, we have governance by the majority that participates. As such, we should be marketing to people what our vision is and how they too can shape the direction of the protocol. People need to know that their financial capital and human capital are valuable or else they will simply go elsewhere.