Reacting to the October 23rd Executive

Hey all, as most of you are aware, the October 23rd executive was passed using 13k flash-loaned MKR by the team at B.Protocol. See this post for details.

The immediate danger of malicious governance attacks is in the process of being mitigated with by the new executive (increasing the GSM Pause Delay to 72 hours.) PLEASE VOTE if you haven’t already.

However, in addition to the problem of malicious governance attacks, we also have to figure out some method for dealing with a flash-loan being used in the manner that B.Protocol used one to pass the October 23rd executive. The problem statement is stated below:

Actors can pass non-malicious governance proposals they have a vested interest in using the available flash-loan liquidity without owning MKR.

Now, in the longer term, this issue will be resolved by the update the DssGov contract. In the short-medium term the Smart Contracts Domain Team are working on a fix as well. However, until that fix is implemented we will need to deal with this no-longer theoretical problem.

Additionally, we need to attempt to come to some sort of consensus as what to do with regards to the October 23rd executive itself. B.Protocol have communicated that they did not have ill intent, however, the actual intent behind the action is irrelevant. The outcome of their actions is that a proposal has passed that was not agreed on by MKR Holders.

The aim of this post is to prompt discussion and hopefully some movement towards a decision with regards to the above issues. What follows is a list of factors to consider.

1. B.Protocol admitted their actions and claims to have meant no ill-intent.

As I hope most have seen elsewhere, @yaronvel admitted to their actions and has claimed to have no ill-intent. Additionally, the B.Protocol platform appears to benefit MKR Holders and the Maker Protocol by reducing the likelihood of liquidations at the protocol level.

It is possible that @yaronvel is not dealing in good faith and just wanted to push the proposal through the executive vote once the possibility of failure became likely. Realistically it’s difficult to judge another’s intentions.

2. B.Protocol’s actions were reckless and they appear to have given little thought to the consequences.

I’m not entirely sure what @yaronvel and others at B.Protocol were thinking when they did this. I can only assume it was the result of a lack of understanding in the Maker governance process and poor judgement or intentional action.

If an actor wanted to showcase a vulnerability in the protocol (which Maker Governance were already aware of) then it makes exceeding little sense to showcase that vulnerability in a vote that directly benefits them, as exploiting that vulnerability throws the result of the vote into doubt, and leads to a post like this.

It’s this point that causes me to doubt B.Protocol’s claims that showcasing the vulnerability was their driving motivation, though I am trying to keep in mind Hanlon’s Razor.

Also worth noting is that B.Protocol have consistently played off the impact of their actions as causing no harm.

3. Failing to react to flash-loans being used in this way invites further abuse of the vulnerability.

Failing to react to B.Protocol using flash-loans in this way invites other parties to use them in the same manner. Namely, to pass proposals that benefit them without owning MKR and being exposed to the consequences.

4. Reacting too strongly to flash-loans being used in this way invites abuse in the opposite manner.

If Maker Governance passes something draconic along the lines of ‘Proposals passed using flash-loans are not valid and should be reversed’ then this is open to abuse from actors that benefit from a certain proposal failing to pass.

An actor could pass a proposal using the flash loan which should then be reverted based on the above statement.

I’m sure there may be additional factors to consider. If you have any other thoughts, please leave them in the comments below and I’ll add them to this post.

In terms of the possible responses we could make, here’s a non-exhaustive list of some ideas in order of severity. To be clear, I am not advocating for any of these, just listing suggestions. It goes without saying that these would need to be voted on before being implemented.

  • Do nothing
  • Require a formal apology from B.Protocol for abusing MakerDAO’s governance process.
  • Revoke the ‘first year free’ for B.Protocol’s oracle access and require them to pay for access effective immediately.
  • Revoke B.Protocol’s oracle access for a period of time.
  • Revoke B.Protocol’s oracle access permanently.
  • A combination of the above.

Once again, if anyone has other ideas on how we should react to this issue, please share them below and I will add them to this list.


This. Let’s focus on improving the protocol. All other things are mostly symbolic.
On second thought, we might ask for ‘formal apology’ to get some laughs in the cryptosphere.


It is my understanding that this flashloan just added some grease in the governance wheels. Everything was already agreed on governance polls. MKR holders were able to express their concerns before the executive. I already stated that I think that their action was legally legit.

Nevertheless, they obviously wanted to have their proposal to pass in their interest (which might be the interest of Maker as well but this isn’t relevant here). Is that a sound foundation for a business relationship? I don’t think so. But mistakes and bad judgement happen.

The response is not easy to define and depend on what we are expected to gain with the B.Protocol relationship, the alternatives, the PR impact, the personal relationships between them and us, and who they are (I would make them pay a bit if they are VC-backed but not if they are without funding for instance).

I would suggest someone study all those aspects and propose something to the governance. I agree with all solutions.

Obviously, the next business partner doing a flash loan in that way can expect more stronger consequences. This sets a precedent.

1 Like

In my opinion I want to believe this was Hanlon’s Razor, similar to what Compound did when Yield Farming took off like a rocket ship. The truth of the matter is–Nobody was going to be oppose to B.Protocol being denied access. And since no MKR holder that were Against B.Protocol did not vote, or could care-less about voting, than–we should do nada, rien, niets, nichts. :slightly_smiling_face:

I believe they did this already via their Twitter Account.

I believe this stifles innovation. I am totally against stopping innovations with good long-term intentions. And I believe this protocol can help Maker, not hamper it.

Again, this is all my personal opinion.


I am also in favour of do nothing.

In my opinion sentences like:

The outcome of their actions is that a proposal has passed that was not agreed on by MKR Holders.


I can only assume it was the result of a lack of understanding in the Maker governance process and poor judgement or intentional action.

are a bit exagerated.

We, the MKR community, knew and were informed about the possibility of these governance attacks for months. At the very least since December 2019 with @MicahZoltu post:

And nothing (or, at least, not much) has been done to prevent them.

It is now our responsibility to take this ``B.Protocol attack’’, as an opportunity to increase the security and efficiency of the system.

Too many MKR holders are not voting. Too many MKR holders are incentivised to lend their MKR, rather than vote in a healthy way. THESE are the real issues.

And hopefully we can start fixing them sooner rather than later, with the help of the new governance code (under dev) and governance discussions here in the forum.


Hey, this is the founder of B.Protocol.

I would like to give a three answer part. First I will present how B.Protocol helps MakerDAO community, and my personal history with MakerDAO. Then I will give some more details on our state of mind during the 23rd vote. And finally, based on that will argue my opinion on why severe steps would not benefit the MakerDAO ecosystem.

B.Protocol contribution to MakerDAO

B.Protocol makes lending platforms more stable, by providing clearer and quantifiable incentives to be a keeper. It is doing that by providing a smart contract interface that shares liquidation proceeds, in return to priority in the liquidation process.

This way MakerDAO gets new and more committed liquidators, MakerDAO users get ETH rewards, and liquidators get more certainty, and avoid the gas wars.

We went live almost a week ago, and currently over $2.5m of user funds were deposited, and over 1M dai was generated.

We spent enormous amount of work bringing new keepers and guiding them through MakerDAO code so they could integrate.

In addition, we have subsidized MakerDAO users with $10k in ETH that were seeded in the contract when going live.

My history with MakerDAO

While I was the CTO at Kyber Network, I led the first integration with Oasis DEX, long before it became the standard to aggregate liquidity.

While designing the WBTC smart contract and its DAO, I helped MakerDAO to try an on-board more custodians.

On black Thursday, I gave technical support, without any payment, to one of the keepers who almost single handedly saved MakerDAO that day.

Hence, when founded B.Protocol, it was only natural to select MakerDAO as a first integration.

The events of the 23rd

A proposal to whitelist B.Protocol contract was put up to executive vote on the 23rd.

On Sunday, the 25th, I started, for the first time, to dive deeper into the MakerDAO voting system, in order to understand the exact time it would be expected to pass.

Already on that day I realized that a flash loan could help speed the process.

I took a conscious decision to deploy the voting contract on that day, and to do it from the same account B.Protocol smart contracts were deployed.

Fully knowing it could backfire on me, out of respect to the MakerDAO team, I decided not to play a cat and mouse game, and to do it with my own identity.

Though I regret not disclosing it in a more responsible way, I am still mostly under the impression that without it, MakerDAO would have been less safe today.

This issue was well known for months, and yet no action was taken.

Proposed verdict

Despite the above, I now realize that my actions led to an unfortunate turn of events.
It forced MakerDAO to act urgently and spend effort on a mitigation, on the expense or working on other great features.
Forced to by the governance or not, I do apologies (we already apologized at our social media), and will make it formal if instructed.

As for the other options, the community should be aware that to date, MakerDAO is one of the most difficult projects to integrate with.
Other than technical difficulties, the white-listing process delays all integrations by weeks.
Integrating with over 60 projects at my time in Kyber, and integrating with other lending platforms, I could honestly say I believe that revoking access could just push away future projects from integrating with MakerDAO.
In addition, personal sanctions in a decentralized world without identity can not play significant role towards preventing such actions from happening.

I paid my respect for MakerDAO by not doing what I did under anonymous identity, and hope MakerDAO community will learn to understand the benefits of B.Protocol and the importance of keeping it operational.


To be clear, I had no prior knowledge of your history, not that I think it’s really that relevant to this particular issue. That said, thanks for what you’ve done in the past to help MakerDAO.

See this is another thing that I find confusing. You mentioned you hadn’t dived into MakerDAO’s voting and governance systems. But then you end up using a flash loan to pass your own proposal. I don’t understand a chain of logic that leads to this that doesn’t include ‘we need our oracle proposal to pass.’

I feel like this is a dangerous point of misunderstanding. A flash-loan doesn’t just speed-up the process. It invalidates the process because after it happens there is no way to be sure of what the outcome would have been prior to the flash loan taking place.

Action was taken when the issue initial arose.

  • The GSM Delay was turned on.
  • Everyone started more carefully monitoring the available on-chain MKR liquidity so that we’d be aware if there was a non-theoretical danger of a malicious proposal being created and passed.
  • A fix was planned for the next update of the governance contract.

I appreciate the explicit apology here. I will note that I checked the BProtocol twitter account and discord. I’ve seen words of regret and claims that you meant no harm. Fine and good, but these aren’t apologies in my eyes.

This is a fair point and is useful input, thanks.

I don’t think anyone is doubting that BProtocol is useful and benefits MakerDAO, that’s part of what makes this whole situation so frustrating. It feels like a massive and unnecessary own goal on your guys part. Something that was a purely good thing is now an issue that we need to give consideration to managing.

The situation we’re in is that flash loans were used to interfere with the governance of the protocol. How governance reacts to that is important, because despite it being a minor interference, it is the first known interference and how we react here will affect how we react to future votes including borrowed (flash loaned or not) MKR.

1 Like

@LongForWisdom , I respect you a lot, but here you are possibly kind of taking your own personal point of view prevail over other ones (remind that your words have heavier weight given your role, and also since you started this thread).

We are in the crypto space, smart-contracts and in numbers we trust. In my opinion the vote is completely valid, because the smart-contract and the blockchain says so.

I personally don’t see why using flash loans should be considered invalid but, e.g., voting anonymously with MKR obtained with illegal money would count as valid.

It’s the blockchain and we have to live in it. This is DeFi.

I am not sure anybody here is particularly interested in apologies, honest or not. I personally just care about improving the efficiency of the system.


Do nothing. The only time we should apply sanctions is if 1) the vote is at risk to cause significant damage to the MKR protocol and 2) the damage was done intentionally or with negligence. Neither can be shown.


Do nothing. I think it was clearly not malicious, did no harm, and calls us to action against this kind of threat.

However, B. Protocol is currently and openly executing an attack on MakerDAO designed to steal the Dai Credit System’s liquidation penalty income. What should be done about that? (also nothing I think, since although they are doing that I think it’s a beneficial attack which will reduce the chances that a Vault is liquidated without recovering debt owed.)


Just to concur with what several others have already said : we should do nothing when it comes to B.Protocol. Any action towards them would only impact the relationship between Maker and B.Protocol. Maybe we want to have an impact there (I don’t think so though). But it would create no incentive against future flashloaned votes. Anyone with a proposal to pass and the means to flashborrow can create however much plausible deniability they wish to.

@iammeeoh I wouldn’t go as far as you: ‘this is DeFi’ for sure but let’s not surrender our judgment to whatever the code does today. We should reduce the expected future impact of flashloans on vote outcomes.


As far as I know, also what I heard from discussions with the MakerDAO team, the liquidation penelty is not part of the MKR token model, and was set to prevent the auction grinding attack


I find it weird to read this attack with so many direct claims pointing to a specific person, and all are made by someone who doesn’t act under his own name and identity.

I have been corrected that LongForWisdem is a known figure.
Just not known to me.

The liquidation penalty predates discovery of the Auction Grinding Attack, however this attack vector ended prior discussions of potentially lowering the penalty percentage.

The reality is that liquidation penalties have provided income to MakerDAO, but that is more of a side effect than it’s main purpose.

I have little doubt that MakerDAO would choose to forgo all liquidation penalty income in exchange for vaults never getting liquidated without full recovery of outstanding debt. Since B. Protocol can go a long way towards making that trade off a reality, I think it’s great.

I was just kind of highlighting how it could potentially be seen differently, though, not entirely unlike how pushing an executive vote over the threshold with a flash loan could be seen in different ways.



@LongForWisdom is the current governance facilitator and leads weekly governance calls.

He is a well known member of the community.



I see
my bad
As an outside reader
it looks weird.


1 Like

Would you view it differently if someone bought MKR, voted to pass an executive, and sold the MKR the next day?


In Dai v1 the liquidation penelty didn’t go to MKR holders, but rather to PETH holders (afaik).

But yeah, your observation is true.
Again, from our sides, the message we got from the team is that this is a desirable outcome. And that it is MakerDAO interest to have others working on liquidation solutions as well.


I think we might be mixing two topics here:

  • The “rigged” vote
  • The repercussions (if any) to the “offender”

Addressing the first topic: if we’re agreeing that this was an offence, and we should take measures against it, then might want to invalidate the vote (roll it back and have it again)? I’m not sure if this is possible and how complicated it is from a technical point, and also if the Community would want that. Once we have secured the system, we should put the vote forward again.

The second topic is what is has been discussed at long in this thread.

It is a good point.
(You would also need to consider that not everyone has access to 6.5+ Million USD; and that’s before we consider any type of slippage, which would be brutal.)
But it is a good point.

1 Like