Greetings Maker community.
There is a lot going on and my apologies to add but I wanted to get this idea off my plate for risk-governance consideration as well as community consideration.
There has been a lot of discussion about attack vectors in the Maker system.
I have in my own analysis identified two primary attack vectors that I outline quickly below.
General governance attack via obtaining sufficient MKR. The first line of defense for the MCD here that has been recently enacted is the 24hr GSM delay, but this still has not been applied to the SCD yet so the SCD is still vulnerable to the this attack.
ES attack. Put simply the idea that anyone with 50K MKR can just lock the system with an ES has implications for liquidity in markets and directly the DAI/USD PEG. If the system gets large enough and enough liquidity with enough leverage can be placed on PEG pairs it is easy to imagine a single player burning 50K MKR to execute what I will call the ES attack on the system. It goes as follows: Prove you can move the Maker collateral prices up/down (either way or both actually) by lets say 10% for X time. Take large leveraged positions on DAI/stablecoinofchoice on the up or down side of the PEG (or even both). ES the system. Drive the collateral prices as you see fit (both up and down), profit off the DAI/stablecoin positions - lose on 50K MKR - driving collateral prices around = profit. I am particularly concerned about this attack as the system grows (DAI) in relation to the market cap of the backing MKR as this attack becomes less expensive relative to the total assets in the system that could be affected.
Lets detail some issues here.
- First a single attacker can carry out either of these attacks at any time. With respect to governance and using MKR to control the Maker system there is no concept of a delay except with respect to the GSM delay now enacted on the MCD only.
Here is what I propose to completely eliminate what I will call MKR control attacks.
First let me define two terms.
- Seasoned MKR - defined as MKR that has not moved in a wallet for some delay period (D > GSM delay).
- Wild MKR - MKR that has moved within delay period (D) and is therefore NOT ‘Seasoned’.
What I propose is that a check be made before MKR is allowed to deposit into the governance contract AS well as the ES. Is the MKR being deposited ‘seasoned’ - if not - refuse to accept the MKR into the contract.
This has the effect of reducing the amount of MKR that can control MKR to being seasoned MKR.
It has the good effect of making it so that no MKR from any source within D delay can control MKR at all (removing it from the pool of MKR that can activate any controls on the system) - no flash attacks. It has the bad effect that anyone who has patience can basically control the system via governance and unless seasoned MKR is in the system waiting to defend against such an attack MKR can’t be mustered last minute to defend against such an attack… There then becomes no concept that anyone has to rescue or support the HAT. The HAT by definition IS supported. The question is once we know the HAT is properly supported how do we know this is still true in the future. As Micah suggested that attackers would proceed more slowly with some stealth - showing up to protect their HAT until they can make sure they have control of MKR so no-one could stop them. I honestly have zero answer under the assumption we have a sufficiently well financed attacker, that has as much time as they want to attack the system that this could not be carried out at any time.
I paused posting this as a potential solution because it led me to wonder how does the Maker community know the HAT is protected? Put simply we don’t and the reason is that we don’t have sufficient clarity regarding the large MKR holders and voters in this system. This weakness regarding the state of the MKR (seasoned or not) in the system I consider to be one of the greatest weaknesses within governance.
Also in conjunction with this was an idea regarding governance voting and vote tallying in the governance portal. It really would be interesting to tally up an alternate vote (not just individual votes vs. MKR voted) but also an idea of MKRYRs. Conceptually here is the idea that 10K MKR held for 2 years probably has more value with respect to voting than 100K MKR held for a week or a day and so it would be interesting to see a seperate vote tally that totals up the MKRYRs voting.
I am posting this now somewhat unfinished because my available time has been narrowing and wanted to see what the community thought of the ideas above. Conceptually I think there should be some delay before MKR purchased or moved should be able to access the MKR control processes (either in governance, ES, or even doing HAT operations). I have a feeling perhaps ideas like the above have been discussed previously but I am simply unaware of why they have been rejected. My apologies if this is the case.
My biggest concern here is that over time as we onboard more people holding MKR and that more MKR is burned and is moving around we are going to lose an important handle on governance that is important for securing the entire system. The GSM 24hrs I think is important step but I think slowing down how MKR can access the system may also be an important step to consider even if it has pros/cons.