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.
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?
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.
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).
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?
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!
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.
What does this mean, practically speaking, for Vault owners?
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.
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.
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:
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.
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 …
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
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?