[Urgent] Flash Loans and securing the Maker Protocol

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.

completely mimics public corporate voting and political voting…

In general, i agree with you. The goal is to incentivize participation in a system. Ownership is one way though passive.

Shy of allocating value to those that vote the alternative is to penalize those that don’t. Neither of those is good options in my mind.

From my lens, a combination of vote delegation (possibly compensated delegation) and L2 / roll ups should help minimize all friction.

as for the rest that don’t vote, the parallel is corporate board voting. Last time i checked if an owner controls 5% of the equity (in a large publicly traded company, eg Coca Cola) he / she has basically a majority on any vote given the average turnout on voting.

1 Like

As this is not the main topic of this thread, I will give a quick response, and look forward to elaborate more on a dedicated thread.

First things first, I am aware that my actions were not the textbook definition of a responsible disclosure, and I do regret that as a result an urgent response was needed. Beside the ethical considerations, i also failed to see that the MKR in balancer is also part of the threat (and without it, the threat was very minor).

Some factual details:

  1. The smart contract that voted with the flash loan was deployed to mainnet more than 24 hours before it was executed. Prior to this proposal I never dived into the MakerDAO governance process.

  2. Nothing was done in a rush, and I deliberately did not try to hide my tracks, despite having sufficient time to use tornado-cash or other means prior to the execution.

  3. The timing of the actual flash loan was dictated by the earliest possible time that would make the vote count.

On a more personal note, B.Protocol brings new Keepers to MakerDAO, and tries to help make it more stable.

Looking forward to elaborate on the above next week.

1 Like

Vote delegation is an amazing idea, giving the trust to someone or some people that we think is gonna vote in a good way will give more vote power to the people that can’t own to much MKR but want to participate in some way.

1 Like

key point also being the MKR holder can also withdraw that delegation …

And what about redirecting part of the dai to be sold to the MKR stacked.

In the real world, there would be no questions that he owned those tokens, even for just a transaction, and was fully legit to vote.

I live in country (France) where the government borrows corporate shares to vote on shareholders meetings and force a vote (interestingly it was to award long term shareholders, mainly himself, with double weighted votes).

Obviously, we should find a fix for that and I am glad that we are already quite advanced.