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.