MIP14: Protocol DAI Transfer

MIP14: Protocol DAI Transfer


MIP#: 14
Title: Protocol DAI Transfer
Author(s): @LongForWisdom
Contributors: N/A
Type: Process
Status: Request for Comments (RFC)
Date Proposed: 2020-05-12
Date Ratified: <yyyy-mm-dd>
Dependencies: MIP0
Replaces: N/A



Sentence Summary

MIP14 defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address.

Paragraph Summary

MIP14 defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. This process is a fallback method of transferring value from the protocol in the event that a more specific process does not exist to do so.

Component Summary

MIP14c1: Considerations Regarding Protocol DAI Transfers
A component which outlines the various considerations that should be made before transferring DAI out of the protocol using MIP14c2.

MIP14c2: Protocol DAI Transfer Process
A process component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address.

MIP14c3: Protocol DAI Transfer List
A list component that lists the previous direct DAI transfers that have been made by the protocol in the past.


Giving governance the ability to use the value generated by the Maker Protocol is beneficial for two main reasons:

  • It allows Maker Governance to incentivise actions taken to improve the protocol.
  • It reduces Maker Governance’s reliance on the Maker Foundation.

Less reliance on the Foundation moves the protocol towards decentralization. Creating a process to allow Maker Governance to spend the value accrued by the protocol empowers Maker Governance to build and improve the protocol in the future.

Specification / Proposal Details

MIP14c1: Considerations Regarding Protocol DAI Transfers
There are several important considerations to take into account before transferring value out of the Maker Protocol.

  • Transfer of DAI from the protocol to an external address that is not controlled by Maker Governance is a one-way operation.
  • Transfer of DAI from the protocol will take DAI from the surplus buffer if available.
  • If there is insufficient DAI available in the surplus buffer unbacked DAI will be created and FLOP auctions will be able to be triggered immediately.
  • If there is a more specific process MIP that allows DAI transfers that is more appropriate to the use case, use that process instead.

MIP14c2: Protocol DAI Transfer Process
MIP14c2 is a Process MIP component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. Note that MIP14c2 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to one or more target addresses.

If a MIP14c2 subproposal is Accepted, The DAI Transfer is appended to the list in MIP14c3 by a MIP Editor.

MIP14c2 subproposals have parameters that depend on the total amount of DAI to be transferred (even if split among multipe target addresses) according to the following logic:

< 10,000 DAI Transfer

  • Feedback Period: 0 full weeks
  • Frozen period: 0 full weeks

10,000 - 100,000 DAI Transfer

  • Feedback Period: 4 full weeks
  • Frozen period: 1 full week

> 100,000 DAI Transfer

  • Feedback Period: 12 full weeks
  • Frozen period: 4 full weeks

MIP14c2 subproposals must use the template located at MIP14c2-Subproposal-Template.md. This template is considered ratified once this MIP moves to Accepted status.

MIP14c3: Protocol DAI Transfer List
This list can be amended through subproposals created under MIP14c2.

List Entry Template
Entries into this list should follow the following template:

Sub-proposal Number: #
Date Ratified: (yyyy-mm-dd)
Amount Transferred:
Recipient Address:

Historical Transfer List
There are currently no historical transfers. Below is an example transfer which should be removed (as should this paragraph) when the first ratified transfer is added to this list .

Reason: Funding Chocolate for Governance Facilitators
Sub-proposal Number: MIP14c1-SP0
Date Ratified: 2020-02-30
Amount Transferred: 1,000,000 DAI
Recipient Address: 0x0000000000000000000000000000000000000000


Links to externals don’t go anywhere (because this was written for the mips folder structure in github) https://github.com/makerdao/mips/pull/31 for the pull request into the github conception branch, in which you can see the initial versions of the other files.

On the whole MIPX thing, I’ll update this once it’s assigned a MIP number.

1 Like

What is this frozen period referring to? We’d pull it out of the system buffer and lock it in some sort of transfer contract? Would love some more explanation there.

The frozen period is explained in MIP0. It refers to the amount of time a MIP or Subproposal must remain unchanged before it can be formally submitted into the governance cycle. For MIPs this is always 1 month (though this is modified temporarily by MIP2) Subproposals are able to define their own frozen periods, which is what that value refers to.

When transferring large amounts, can the FLOP auctions be staggered out over of time? For example, if we want to raise 2M DAI then can we run 500k FLOP auctions spread out over 4 weeks? Is this technically possible?

I seem to recall that FLOPs could be paused and restarted, but maybe that was a bug?


Might be something @Kurt_Barry could weigh in on?

Actually we can and should probably define a transfer increment even though we may have a large total.

So I would suggest we amend MIPXc2 to have a maximum transfer increment to limit flop auctions generally.

Something like

  • If DAI to be transferred exceeds current surplus transfer surplus or 100,000 (example) DAI which ever is greater
    a) In this case we may want governance approval but if the subproposal is adopted by governance there probably will already be provisions on how to pay for this included if the surplus isn’t sufficient.
  • Have condition to be fulfilled before next 100,000 DAI can be transferred if surplus doesn’t have it.
    a) Wait time
    b) MKR flop auctions to complete.
    c) Other? (governance approval)

I think we should also consider the idea of having a place to accumulate these transfers that governance can control until sums can accumulate before being disbursed out formally.

Just a few thoughts. Though conceptually this MIP is important.

I am not sure if this is something for this MIP or another but conceptually Maker will need a DAI cash account seperated from surplus I think to deal with known cash expenditures (salaries, oracle payments, maintenance and operations bills etc.).

Something else to know from an accounting stand point is that we will need to have a Catagory or account # for MIPXc3 here for account tracking beyond Reason: This could be a DOI MIP number. The idea of having a catagory is for searching and account tracking. This can have multiple entries. Administrative, IT, development, documentation, data, analysis, oracle, insurance, legal, etc.


IIUC the scenario, we’re talking about sucking 2M DAI into existence. In that case, as the system stands now, the flops would begin immediately. We were able to delay the Black Thursday flops because that bad debt came from liquidations and was thus in the sin queue, which has a modifiable time delay before it releases debt to auction

But…why not just raise the 2M DAI over 4 weeks in chunks of whatever makes sense? It should be rather rare to need to generate 2M DAI via MKR all at one time.


Agreed, not least to differentiate budget that is there to soften unexpected impact from budget that is used for planned expenses.

I may be misreading the code, but doesn’t suck also add to the sin queue? And in that case, couldn’t you kiss it before it goes on auction? Even if it goes on auction, I thought you can heal from the surplus before the first bid. (Of course both scenarios are relevant only if the surplus is positive and sufficiently big at the time).

1 Like

These kind of sentences do not belong in MIPs, imo. It is not future-proof, nor does it provide any helpful information.

I also agree with @MakerMan that the logic for transfers can be improved. Rather than just categories of 0 - 10 000, 10 000 - 100 000, and > 100 000, why not make specific reference to the surplus buffer?


Fair enough, I agree it doesn’t really add anything. I will take it out once this moves to RFC.

In what way? I don’t want to add something like 'this can only be done if there is sufficient DAI in the surplus buffer, because there may be times we want to transfer DAI regardless of the health of the buffer.

Separating a single transfer into multiple smaller amounts is problematic from a governance perspective. It would require passing multiple executive votes over multiple months. The chance of one or more failing becomes higher due to bundling.

I think much of this can be handled on the governance layer and other MIPs. If MKR Holders want to postpone a payment until there is sufficient surplus they could pass a Declarations of Intent MIP with that intent. Individual sub-proposal authors can seek feedback on a transfer subproposal before posting it and potentially split it up manually in response to feedback.

I guess my point is that I’m not sure that we need logic inside of this MIP to support this behaviour. It’s meant to be a functional fallback option, rather than include lots of complex logic.

Unfortunately, you are misreading the code, although don’t feel bad as it’s kind of the code’s fault for re-using names.

You’re conflating Vat.sin, which is the per-address unbacked debt, with Vow.sin, which is the actual sin queue (see here). suck is adding to the former. The only way to add to the sin queue is to call Vow.fess.

Btw, if there’s sufficient surplus to heal all debt, the flops will never start in the first place.


So if we sucked DAI out and it pushed us into bad debt, FLOPs would start immediately?

If that’s the case I will add something to that affect in MIPXc1. Currently it says this:

Which is incorrect?

Assuming the conditions in the flop() function are satisfied (or can be satisfied with some initial calls to heal and/or kiss), then the flops() could be started immediately (a Keeper has to make these calls, of course).

We could be really hacky and remove the Vow's authorization on the Flopper to block them, I suppose, but as soon as you re-authorize, they can still all start at once, and IIUC the goal isn’t so much a delay, but rather a titration.



One of the few times we might disagree @LongForWisdom I think if Maker wants a MIP for DAI transfer we really want the mechanics of these transfers to be dealt with in this MIP. What did we have as a criterion for a good MIP - that it was complete.

Regarding governance. Once governance approves a transfer having the actual mechanics in place to actually perform the transfer in a way that:

  • Takes into account what the surplus buffers is. If sufficient no problem - do the full transfer. If not then manage this in such a way as:
  • We don’t completely thrash the MKR market with some huge flop auctions (i.e. control the rate at which MKR is sold). This is critical not just to proper market functioning, getting the best MKR price, but also for our MKR investors.

These are some basic steps. Now I can see perhaps one might want to construct another MIPX: MKR flop auction management but then one is going to have to change smart contracts which we all are agreeing we don’t want to do. We want to use the mechanics of the system as it is NOW to manage this and it was my understanding if we do progressive suck()'s and whatever else needs to happen we can completely manage the flow of MKR to flop auctions in such a way as to mitigate any issues. From the point of view of raising DAI it makes sense then to put the mechanics of how we are going to raise the DAI from a surplus and flop in the Protocol DAI Transfer because if the system doesn’t have surplus this will become a governance issue directly.

As to having multiple governance votes to do multiple transfers I think this is a moot point particularly from putting the actual DAI raising mechanics into this MIP. Because no matter what the accumulated DAI necessary to raise it would simply be scheduled into the next system spell as usual until the DAI is raised and has been put into the temporary working cash DAI account and ready for disbursal.

The issue with this is that Governance cannot approve the transfer without doing the transfer. If we wanted to be able to do this we need to somehow bind the protocol to actions in the future without further votes. It’s doable with a smart contract, but that adds a level of complexity to this MIP that it does not currently have.

It’s possible this would be doable within an executive. I will maybe follow up with devs some more.

There isn’t a working DAI cash account right now, there is only the system surplus. Sucking into the system surplus is a inefficient way to do nothing.

Also, including a suck into each executive until it passes is really dangerous, as it risks all the execs failing if the decision to suck has changed or only barely has consensus.

We can’t really rate limit FLOPs in the current system. The best we could do is split up a payment across multiple subproposals. However, there is no point having a process for this written in the MIP, because the process wouldn’t be binding.

Imo the best option is leave all of that complexity out, and allow governance to choose to do smaller subproposals to rate-limit FLOPs, or to wait until the surplus buffer has a sufficient amount of DAI on a case-by-case basis. If some reliable convention arises from these case-by-case examples, then this could be codified in the MIP.

I think there are a few points here:

  1. Maker needs a seperate DAI cash address where DAI can be accumulated seperately from Surplus
  2. There exists no mechanics to control the subsequent MKR flop auctions if the surplus is not sufficient.
  3. Because of the whole governance bundling issue all governance actions need to be carried out in a single executive.

I think the biggest issue doing anything with this MIP is that governance may balk if we don’t have funds available. Which might bring me to a point

  1. We might want to do a poll on what governance wants to do about system funding now that our surplus is only 55K. Do we ask Maker Foundation to kick back some DAI into a governance controlled MKR fund, flop more MKR, or wait.? Do we need the cash this instant? No.
  2. Increase surplus buffer?! If we create a cash buffer account seperate from the surplus we probably don’t have to change the surplus buffer just have governance vote to suck() from surplus into the buffer account before the system starts buying MKR. If we don’t have or use a seperate cash buffer we will definitely want to raise the Surplus buffer level.

I point out while these issues are related they are somewhat orthogonal to the MIP: Protocol DAI Transfer. But I can say if this passes and we also get the MIP for Declaration of Intent we are going to quickly need a cash buffer account, and are going to be suck()ing on the surplus and probably at some point triggering MKR flop auctions. All of this is going to come up and could be a real hitch to passing DOIs. Just keep this in mind when assembling. I consider this MIP a key component but there may need to be additional MIP components to actually make this function in the way you are envisioning from a governance and executive perspective.


Maybe but i wouldn’t accept that as a fact at this point. There were tons of concerns about taking large amounts of DAI out of circulation that were brought up by this thread.

I agree with this in principal. I’m assuming this would require making a separate smart contract module. Also need to determine what happens to funds in the separate cash account if ES is triggered due to critical bug or governance attack.

1 Like

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