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?
6 Likes
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.
1 Like
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).
15 Likes
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?
2 Likes
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!
3 Likes
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.
5 Likes
What does this mean, practically speaking, for Vault owners?
4 Likes
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.
2 Likes
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.
1 Like
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:
- Freeze the oracles.
- Prevent Liquidations.
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.
3 Likes
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.
5 Likes
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.
6 Likes
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%)
3 Likes
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.
5 Likes
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?
3 Likes
@chonghe There was also some time pressure for last Friday’s executive. Needed to be passed by Monday, before the Monthly MIPs bundles executive.
2 Likes
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.
8 Likes