MIP14: Protocol DAI Transfer

@Andy_McCall Yeah thanks for reminding me not just about the implications of actually having a working account in DAI to liquidity. I remember making a suggestion that Maker actually could use DAI to purchase assets that were anticorrelated to collateral prices to help manage liquidity issues.

One would sell assets for DAI to actually mop up DAI liquidity. One would purchase assets for DAI to provide DAI liquidity. This I saw as a direct DAI injection/removal method.

Not sure this would fly at all given the centralization risk but Maker could just purchase other stable coins (PAX, USDC, USDT, whatever) with DAI in such a surplus account pay out to people using those. It makes things a little more tricky from an accounting perspective but it does allevaite this accumulating cash (in DAI) liquidity issue. This is a whole other asset and account management is an issue to be sure. But is a valid approach that alleviates pulling DAI out of markets.

I remember not just when Maker system liquidated effect on PEG (normal) but the after effect of this when MKR was flopped sopping up another 5.3M of liquidity to fill the surplus gap.

Who is to say? There certainly seems to have been a relaxation of risk aversion as it pertains to centralization risks given the times we find ourselves in. Who knows how that will play out ultimately, but i find myself unable to predict the sentiment of MKR governance as it pertains to centralization.

Would love to talk more about the idea as i think it is more or less how i would envision things might work. This may not be the best thread for a deep dive into that though. Maybe discuss it more on the system reserve thread?

1 Like

I posted to bump that thread as well since a lot of good minds were noodling on the System Reserve topic.

Updated with assigned MIP number, and moved to RFC.

1 Like

I’ve made minor wording changes to fix the issue Kurt brought up, and to remove the sentence Andy T brought up.

Github RFC branch can be found here: https://github.com/LongForWisdom/mips/tree/ProtocolDAITransferRFC/MIP14

Free free to make PR’s, leave comments here or hit me up to discuss.

I would also like to draw attention to the MIP14c2 Subproposal Template located here: https://github.com/LongForWisdom/mips/blob/ProtocolDAITransferRFC/MIP14/MIP14c2-Subproposal-Template.md

This will also be ratified if the MIP is accepted.

@Kurt_Barry if you could take a moment to look over the executive code snippet in there and potentially improve upon it, that would be appreciated.

1 Like

I think at the schematic level, the code snippet is fine, and I don’t think there’s much point in trying to take it further than that (e.g. who knows maybe someday we’ll write executives in Vyper instead of Solidity or something).

2 Likes

Does anyone have further comments or ideas on how to avoid FLOP auctions without making the MIP much more complex? I’m open to PR’s or to discuss the subject in the chat too if someone does want to try to hack something together that takes it into account.

One option is to just explicitly write in the MIP that this MIP can only be used once there is sufficient system surplus to cover the suck. But this feels overly limiting, and I’d like to keep it as flexible as possible.

Based on the lack of feedback regarding avoiding FLOP auctions, I have decided to submit MIP14 into the governance cycle for June.

@equivrel made some good points on the most recent governance call about explicitly disallowing transfers that trigger FLOP auctions in this MIP. While this would provide an extra layer of protection, I believe that it would limit governance’s ability to take action in times where they may want to transfer DAI despite triggering FLOP auctions.

Limiting the process in this way runs counter to the intent for this MIP to be a generic fallback process for governance to transfer value in a formalized, recorded way through the MIPs process. Ultimately, each transfer subproposal is also required to pass through the MIPs process, and I feel that the correct time for voting against FLOP auctions would be at the individual proposal level rather than the process level.

3 Likes

Here are the reasons I did not vote to support this MIP. Please go easy on me, I’m still learning how to govern :smiley:

  1. FLOPS: I felt uncomfortable having the max limit of the protocol’s first credit card be the entire MKR market cap. I am not against amending this MIP to include FLOPS as a funding option in the future, I just feel more comfortable knowing that the worst-case scenario is the 500K surplus cap. Also, lets practice spending money responsibly before we make it possible to dilute MKR holders. Training wheels are good.
    Sub-reason: Would FLOPS for funding create a new attack vector? If we were worried about a governance attack, however unlikely, we are also providing a direct route for hyper MKR dilution
  2. Address clarity: I was confused reading the MIP to where these funds would be directed. Are they going to individual vendor addresses? An address controlled by a benevolent treasurer? Will it be a multi-sig wallet that community members oversee and disperse? Do we have to whitelist these addresses? Who will be in control of that?
  3. Oversight: I did not like that we were creating a tool without a plan to responsibly audit that tool. Sure we can pass a vote to issue money, but will the collective governance complete an audit to ensure those funds were spent responsibly? I think there are a great deal of questions we need to answer regarding the flow of compensation (How do we decide how much something is worth? What frequency are we authorizing payments? If funds are limited, how do we prioritize? What is our budget?)
  4. Scalability: I interpreted this MIP as needing a subproposal and executive vote for every line item that came across our collective desks. In the future, hopefully we will be able to regularly issue hundreds (thousands?) of payments, and I don’t think executive governance has the bandwidth for that.

If you were to ask me - how do you think the DAO would use the protocol for recurring payments? I would think it would be something along the lines of… the community votes-in a billing domain team, they are responsible for assigning values to items/tasks, they package multiple line items to create a budget that is monthly/quarterly and submit it to the community in a transparent way for approval (possibly as a MIP sub-proposal :smiley: ). The funds are then released (to a multi-sig wallet?) and dispersed (and audited).

Please let me know if something I posted was a gross misunderstanding of the MIP proposal!

Thank you for letting me practice governance!

7 Likes

Good points and thinking @Jtathmann. Welcome aboard btw!

  1. I think having a DAI limit on these is good, but see comments below regarding scaling. With regards to limiting flops I think a more appropriate discussion centers around creating a secondary surplus buffer that can take DAI from the working surplus and buy other assets that could be used as cash for operations. And then applying this MIP to that secondary buffer. What no-one has talked about is that other companies often sell bonds to raise cash if they need operating capital. I think we should have that discussion since I want to create as many buffer rings around MKR dilution as possible for oh so many good reasons.

  2. Clarity. The MIP said the funds would go to a specific address. But then again I had the idea that MIP13 would signal a declaration of intent and then make at least a deposit because why would someone work on satisfying a DOI if they ended up with 0 funds. A vendor won’t sell you anything unless they have an upfront deposit and contract in hand and even then a lot of vendors want payment up front unless they are dealing with a well respected and known buyer they can legally go after if something goes amiss. I do agree clarity with regards to details and conditions of fund disbursal needs to be looked at. I personally think this part alone with make this MIP unwieldy and probably needs to be in another MIP regarding fund release in connection with MIP13 DOI contract performance as well as upfront payments non-refundable earnest deposits.

  3. Oversight presumably would occur on high level DOIs with governance but in general agree that a business operations group would probably have to have input and deal with the day to day smaller stuff. With large size contracts due to the amount of effort that goes into satisfying them this will mean breaking those into smaller manageable pieces from an oversight and Q/A point of view. Oversight probably needs to be another MIP which itself will be complex unless some kind of Maker business group is formed. Realize here somehow funds are going to be needed to pay elected positions (Cyrus with risk, and LongForWisdom + Rich on the governance side) Not to mention recurring and one time operational costs for development bug fixes etc.

  4. Good point on scalability again a reason for a business group that deals both with accounting and quality assurance (we got what we want). But doing this from a centralized group (even if elected) is far different than governance portioning out these. I agree with you that this kind of thing doesn’t scale well given current governance structure. I liken this to stockholders micromanaging capital outlays of the company they own down to the penny. We simply don’t want to do it which perhaps means there should be some kind of scale put on these things. governance simply doesn’t need to micromange 10-10K DAI but definitely needs to have some flow control over > 500K DAI. This is a greater governance and community question. How do we see DOIs being completed and funds disbursed to assure quality of service. One way is to have vendors put up MKR in exchange for a deposit on a DOI contract that could be slashed if performance metrics are not met. Or really one would just put a contract payout conditional on meeting timely goals. The intention wouldn’t be to slash the MKR stake but really to make sure the entity seeking to take on a DOI and getting a non-refundable DAI deposit has a real stake on the contract. This is one idea which has issues to be sure. As this is discussed perhaps other better ideas will come up.

BTW: With regards to recurring payments there are many options. One is to look at life of contract and simply fund for something like 6-12 recurring payments and then simply have some kind of business org deal with the day-to-day funding operations payment disbursals and verifying service quality. Typically this involves having departments and departments submitting budgets. Auditing can be done on-chain pretty easily - catagorizing the quality of service or hunting for better suppliers/workers is a constant process that governance probably doesn’t want to micromanage. Putting this on-chain as well will lead to extra expense but can then be fully audited to determine quality of service against cost so optimization stratagies can be applied to manage expense growth and reward business individuals who cut costs and improve service. This is a tricky area and if we have a centralized group doing this we end up with all kinds of back door schemes to raid the coffers so to speak.

You are right that in connection with fund disbursal there are all kinds of checks and balances that need to be discussed in association with that one issue.

2 Likes

Appreciate you providing your reasoning for voting against this @Jtathmann, but I don’t think I agree that any of these points are a good enough reason to not implement this MIP.

The main argument against this seems to boil down to ‘we’re worried that someone will spend all the money in a way that wasn’t possible before.’ This is a bad argument for a couple of reasons:

  1. Everything in this MIP is already possible within an executive vote. If the Maker Protocol desperately needs funds for some reason (to the point where it will fail if we don’t use them) then they’ll be used to save the protocol. The question we should be asking is that if in a situation where we need to dilute MKR, do we want to be doing it with a clear process in place, or do we want to be doing it with no clear governance process beyond the signalling requests in the forum.

  2. Spending DAI like this requires an executive vote. Approving this MIP isn’t the ‘last chance’ to prevent MKR dilution, there will always be Sub-proposals that need to go through the month long governance cycle before they are actioned. Prior to that governance cycle, there is a fixed feedback and frozen period that must be observed (the length of which is determined by the amount minted.) There will always be time for governance to raise the roof about potential dilution before it happens. Furthermore, as Facilitator I’d consider it part of my job to make sure that everyone is aware of a potential MKR dilution event, and has the chance to vote on the issue.

Furthermore, there are some really good reasons to not explicitly prevent minting beyond the surplus in this MIP.

  1. The surplus can change swiftly, what if a sub-proposal is created when there is surplus, but by the time it comes to ratification, the surplus is no longer available?
  2. We can’t prevent MKR Holders from minting from the surplus if that is what they vote to do. Not having an avenue for this action doesn’t negate the reasons for taking the action, meaning if MKR Holders really wanted to do this, then they’ll do it using whichever process is most appropriate. Currently the most-appropriate process is the signal request process, which has a much shorter lead time, and is much more informal than the one laid out in this proposal.

I’d actually appreciate more feedback on this. The actual template for doing a MIP14c2-SP is located here, and maybe helps explain this better: https://github.com/makerdao/mips/blob/RFC/MIP14/MIP14c2-Subproposal-Template.md. If you’re still confused then I’ve done a bad job of explaining it and I’ll happily make it more clear.

This is a fair point. But I would counter with the idea that perfect is the enemy of good in this situation. This is the first version of this MIP, I’d be happy to see it expanded in the future once we have a better idea of what sort of oversight is required and who can best provide it. We made this mistake with the onboarding process (fully specifying how everything would work before it was done in practice) and now as a result we’re having to amend the MIPs every cycle and we still don’t have something that is consistent and working.

Yep, you’re absolutely correct on this one. But again, I don’t think it is worthwhile to prematurely optimize for scale when in all likelihood this is going to see very little use for the next year or so. Once we have a better understanding of usage patterns, we can make this MIP more complex (or create new MIPs to supercede this one for certain cases.)


Regarding recurring payments, I agree that this is not an ideal solution, and I expect we’ll see additional MIPs in that area at some point in the future.

3 Likes

As a more general point, I’d also love to get feedback from anyone else who voted against this. What are the minimum changes you would need to see to vote in favour of this? What are you reasons for requiring those changes?

In terms of making progress with the MIP, I’m at something of a loss without feedback. So far the arguments presented against ratification haven’t convinced me that this is a bad idea as written.

One of the reasons for pushing this now is to help provide the tools necessary to provide compensation to Vault Holders that lost money in Black Thursday. It’s almost certain that this compensation will require more money than is currently available in the surplus buffer. Unless governance explicitly votes that they do not intend to compensate Vault Holders using MKR dilution, a MIP of this nature is required sooner rather than later.

6 Likes

I think this needs to be open back up for discussion, what does a better version of this proposal look like? The fact that MIP14 didn’t pass causes problems for the Black Thursday compensation plan, but it also means we have no framework for paying employees for work. We will have to do this in the future as the foundation delegates more responsibility to the community. Some of these employees include:

  • domain teams: risk, smart contract, oracle who onboard new collateral
  • community developers, designers, content creators
  • Probably funding SourceCred?
  • Governance Facilitators
  • I’m sure there will be more positions that add value in the future and will want to be paid for the work they are doing

It is hard to imagine our community/makerdao scaling much past its current size if we have no accepted process for paying people.

2 Likes

After reading LFW response, I realized a lot of my concern was HOW MIP14 would be used/managed, and not so much with the base function of the MIP. I’m still not 100% sure why FLOPS are necessary from the get-go though :confused:

2 Likes

I’ll clarify a little more…

I’m not sure I support the logic of – if not enough surplus, then flop

If we are engaging in a flop, could it be more explicitly called for?

1 Like

It’s necessary to take into account the possibility because every governance action that MKR Holders can take in the Protocol should be covered by a MIP. By excluding it, you don’t prevent it from happening, only prevent it happening using the MIPs process. If you don’t take it into account, then it just means that it can happen without following agreed upon rules (rules such as ‘this must be discussed for at least 3 months before being implemented’.)

I would also say that the negative impact of FLOPs is largely dependent on degree. It might be that we’re willing to trigger 10k worth of FLOPs if it means paying a contractor on time and preventing reputational damage, for example. Whereas we probably wouldn’t be willing to pay 500k to fund a new project. The point is that the use of FLOP auctions is largely dependent on the context surrounding the transfer of the funds, by either not-mentioning or prohibiting it in the MIPs, the result is an attempt to bind the future actions of governance.

Fundamentally, governance cannot prevent itself from acting, because it can always go outside of the MIPs process to achieve its goals. We want to limit the need to do that as much as humanly possible. Outside of the MIPs process, decisions become more dangerous because they are more prone to following informal processes that MKR Governance hasn’t agreed upon.

I could add something explicit to the sub-proposal template in the preamble along the lines of ‘Do you expect this to cause a FLOP Auction?’ Maybe you could expand on what you’d like to see in terms of explicitness.

1 Like

When we did the poll for vault compensation we included in the describption’Vault holder compensation will be paid for with additional flop auctions.’ So MKR voters were pretty aware of where the funds were coming from. My impression is that MKR holders are much more willing to spend surplus than to dilute MKR supply. My worry is that having the possibility of “surprise” flops will prevent funding from getting passed.

Maybe we can just make it convention that when we put up a budget we can say, pulling from surplus only, or pulling from surplus and flops if needed.

I’ll also add that there were 16,257.72 ‘No’ votes for MIP14, and I abstained from voting. So I presume there are other issues that we have yet to discuss.

Come on team, don’t be shy!

4 Likes

Again. One very simple tool to manage the PEG and to provide liquidity not just for operations or compensation is to be able to run the system with a negative surplus as this would signal to all DAI holders that their DAI is now worth < $1 USD in an ES. Most normal markets would take DAI that was selling at 1.01 USD and drop the price to 1USD if the backing assets dropped by 1%. Or say Maker governance decided to run with a negative surplus of 1% (now currently about 1.6M DAI) and to do this until the PEG comes back into line.

People want to keep the DAI backing at a 1:1 or manhandle markets with a PSM. Don’t get me wrong I believe we need more tools and to expand DAI liquidity with more assets but if the markets are telling us that DAI is worth more than $1 USD even if the backing is only worth $1 then perhaps the simplest way to manage this is to simply allow the system to run with a negative surplus and use the minted funds for:

1a) Market operations to buy secondary reserve assets outside the normal system ES (during ES these can be voted in by governance or NOT). This has a double effect of being a real drop in DAI backing value and a psychological one (for good or bad) that should have an effect as a tool to manage the PEG. The bad effect is people thinking their DAI is not worth $1. But heck why was it worth 1.02 or 1.01 when backed by $1 of real assets?

1b) Use these DAI to direct inject and remove liquidity by buying or selling assets. Hence there is a 2x multplier to 1a with 1b because it isn’t that we only reduce the backing value of DAI from 1:1 to .99:1 but we also inject said liquidity into markets by buying assets that sit in a secondary reserve outside the primary system. THis has an additional effect of acting as a real reserve which can be used before we flop MKR to bring system back into line (of .99 USD value for 1DAI) before an ES say due to accumulating losses.

  1. Use the funds for operations. Since it is a negative surplus this will automatically reverse when PEG goes under 1 and SF can be increased naturally making the negative surplus go away ‘automatically’ (for 1a,1b,2)

  2. We could even use this fund to floor the MKR price and then when we have surplus and want to sell MKR do it at a higher price. I am not saying to do this but it is possible.

I literally have not thought of all the ways the above could be used but if we are talking about tools here to manage the PEG I find it interesting no-one wants to give up even a little on the $1:1DAI backing to affect the PEG positively.

2 Likes

Now being worked on by @Jtathmann here: MIP14: Protocol Dai Transfer Update

3 Likes