MKR seasoning proposal for system control access

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.

  1. 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.

  2. 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.

2 Likes

I hope more people look at this.

I dont know how etherum works super well, but a function like this could maybe help mitigate an attack from https://www.scopelift.co/blog/fakerdao which allows the ability to auction mkr away voting rights for 7 days through a dao. MKR locked into this sort of contract would have to be “wild” mkr since it leaves the holders wallet to be locked into the fakerDAO correct?

I’ve always been confused about how addresses/smart contracts interact exactly. I am going link this thread and see if any of those people think this would help. Heres the reddit thread in r/ethereum https://www.reddit.com/r/ethereum/comments/fh0uno/fakerdao_demonstrating_a_weakness_in_makerdaos/

Based on my interpretation, this is hinting at on-chain reputation or which MKR holder should be entitled to voting … Is that fair @MakerMan?

In this case of MKR YRs, I think it is a relative constraint that would increase the cost of an outsider getting access (i.e. even if 100k MKR held for a week could be valued less than 10K held for 2 years, the actor could up the stakes and just hold 150k MKR). This would create a marketplace for how much an outsider is willing to pay to get voting rights. Also, @Mitote from my understanding, FakerDAO is essentially looking to stress test this case. Essentially, if dormant/non-compelled/extractive MKR holders were looking to collect rent on their voting rights, what price would create a market if this was automated?

In the case of seasoned vs wild MKR, I think this is an absolute constraint that is worth discussion - have voting shares vs. non-voting shares been discussed in the community before? (I’m new here). It would address the 1of the 2 reasons that FakerDAO purported - that some token holders could have MKR -

To earn a return on MKR when it appreciates in value, i.e. a speculative investment

perhaps not to

To gain the right to participate in governance signaling

Additionally, these topics could probably feed into some of the discussion that I am sure the source cred initiative have already thought of …is this fair @LongForWisdom or is source cred solely about unifying social identities?

Rich

I appreciate the response. The thinking here with this proposal was to pretty much eliminate any sort of ‘instant’ type attacks. Including ESing the system. Think about this. A person holding 1000 MKR for 2 years has had to ride up and down wild price fluctuations, they may or may not have particpated in goverance, or been a developer or whatever. In effect this person and MKR for that matter is much more valuable with respect to the Maker community than some whale yahoo that buys 150k. I am not saying to ‘devalue’ the Maker.

Perhaps I should apologize because within the same proposal I have two proposals. One that simply suggests a Delay related to whether MKR wanting to control anything in the ecosystem is allowed to participate in any of the control functions (governance, ES, HAT control, etc.). The second proposal is something that came up with respect to the first. What is the age of MKR currently guarding the HAT and voting.

With regards to anything about FakerDAO I am not familar with the details of that project to comment.

Also pay note. I did not post this proposal because of some serious concerns over whether using any kind of ‘seasoning’ mechanics to accept or deny access to Maker control functions had more pros over cons which I elaborated in the proposal. I simply put it out as a consideration. Why would the Maker community give the ‘same’ access to all Maker functions to someone who literally had money but no time in the system (not as a longer time MKR holder, not participated in governance, maybe doesn’t know dink about the system). At least the seasoning means anyone buying MKR better understand what they are getting into before they basically are allowed to access Maker controls. In my mind D being even a month is still too short. But again we are back at pros and cons of the proposal. I simply leave it for consideration because I think the implementation details are trivial and they grandfather in everyone with MKR deposited in the governance contract.

I will add that if this seasoning test is applied to the ES it will mean that we will need seasoned MKR sitting waiting to deposit in the ES and frankly I would rather all MKR looking to control the system be deposited in governance before being allowed access to control the HAT, ES or whatever. This way pretty much all the Maker in governance is the only MKR that can control the system and personally I like that as a cleaner solution to all the different ‘wild MKR’ attack scenarios being tossed out.

2 Likes