en.cryptonomist.ch
As reported on the official MakerDAO blog, there were some governance issues during the last vote.
Last week the community voted for the increase of the surplus buffer from 2 million to 4 million and for the BProtocol whitelist on the ETHUSD oracle, OSM, and a flash loan was used to pass the vote.
An Executive Vote has been added to:
📈Increase the surplus buffer from 2M to 4M
🔮Whitelist B.Protocol on the ETHUSD Oracles (Medianizer + OSM)More info can be found here: https://t.co/6deJrBTBOO
MKR holders can vote at the NEW voting portal here: https://t.co/g9vSgxm089
— Maker (@MakerDAO) October 23, 2020
The data shows that about $20 million in Ethereum has been borrowed from dYdX, about 50 thousand ETH. These were then deposited on Aave and about 7 million dollars were borrowed in Maker, corresponding to 13 thousand MKR with which the vote was cast, locking them inside Maker until the vote took place.
The problem doesn’t end there: not only using borrowed funds to pass a vote shouldn’t be allowed per se, but it turns out that it was the BProtocol team that made that flash loan to pass the vote and be put on the relevant whitelist.
The MakerDAO post continues and also explains how there are about 63 thousand MKR that could be used for this flash loan procedure and therefore alter votes, even if they are not enough to affect a proposal since the hat is about 79 thousand MKR. In any case, it remains a risk not to be underestimated.
Solutions for the governance of MakerDAO
Some suggestions include bringing the hat to over 100 thousand MKR and releasing the funds after 1 week, thus mitigating the risk of other similar cases.
Moreover, the MakerDAO team has prepared a proposal to increase the GSM delay up to 72 hours, de-authorize the OSM (Oracle Freeze Module) and de-authorize the Liquidation Circuit Breaker.
Surely in a system that involves voting, there is always the risk that those who have too much liquidity can intervene to approve or reject a proposal, not to mention the exchanges that can intervene at any time to destabilize the same protocol, which unfortunately happened in the sad case of TRON with Steem.
At the time, in fact, Justin Sun had exploited the support of several exchanges to change the fate of the relative protocol, so the exchanges had in fact expropriated the users of their tokens to use them to vote. All this without informing the users.