MIP14: Protocol Dai Transfer Update

Maker Improvement Proposals Formal Submission
,
#1

Hello! I made some updates to MIP14 based on the informal poll to improve MIP14. The takeaway was that MKR voters are not comfortable with token dilution at this time. The updates to MIP14 were largely made to avoid FLOP auctions.

One thing to add, during this process I learned that the protocol allows MKR holders to cause a FLOP at will, and MKR holders will ultimately be able to avoid MKR dilution if they wish

Highlights of the changes:

Added MIP14c4: Dai Transfer Ceiling. This would allow for MKR holders to set the maximum amount of DAI that can be transferred from the protocol in total using this process. This ceiling would need to be raised by sub-proposal, adding another layer of FLOP security.

Adding a surplus analysis section to the MIP14c2 sub proposal template, which would require sub proposals to declare whether a FLOP would likely occur due to DAI transfer

Requiring Governance Facilitator(s) to communicate to the community that a FLOP would occur if the transfer proposal cannot be taken from the surplus

PR: https://github.com/makerdao/mips/pull/84

MIP14: Protocol DAI Transfer

Preamble

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

References

MIP14c2-Subproposal-Template.md

MIP14c4-Subproposal-Template.md

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.

MIP14c4: Protocol DAI Transfer Ceiling
A process component that allows governance to define and modify the total amount of DAI that can be transferred from the protocol using MIP14

Motivation

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

If a MIP14c2 subproposal would result in a FLOP auction, Governance Facilitator(s) will use established communication channels to ensure the community is informed

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:

Reason:
Sub-proposal Number: #
Date Ratified: (yyyy-mm-dd)
Amount Transferred:
Recipient Address:
Total DAI Processed by MIP14 to date:

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
Total DAI Processed by MIP14 to date: 1,000,000

MIP14c4: Protocol DAI Transfer Ceiling
MIP14c4 sets the maximum amount of DAI that can be transferred in total from the protocol using this process. MIP14c2-subproposals will not be eligible if they cause the historic amount of DAI transferred from the protocol to exceed the ceiling, which will be initially set to 250,000 DAI and can be modified by MIP14c4 subproposal

DAI Transfer Ceiling Adjustment

  • Feedback Period: 4 full weeks
  • Frozen Period: 1 full week
9 Likes
MIP14: Protocol DAI Transfer
Maker Relay Ep. 16 - PT-BR PortuguĆŖs
Maker Relay Ep. 16 - en espaƱol
Maker Relay Ep 16
Maker Relay Ep. 15 - PT-BR PortuguĆŖs
Maker Relay Ep. 15 - en espaƱol
Maker Relay Ep 15
Relay Ep. 14 - en espaƱol
Maker Relay Ep 14
Maker Relay Ep 10
#2

It might also be worth pointing out what our protocol peers have been able to accomplish

1 Like
#3

Thanks for taking this on @Jtathmann!

Some feedback:

This is an interesting idea, and Iā€™m looking forward to seeing others thoughts on it. Some comments on implementation:

  • If MIP14c4 is a process component (ie you can create subproposals using it) then it should have a defined feedback and frozen period.
  • The ceiling and total amount transferred should be recorded somewhere, probably in the MIP itself.
  • Formatting-wise there should probably be a newline after the MIP14c4 title.
  • Iā€™d be tempted to reword the component summary slightly. Maybe: ā€˜A process component that allows governance to define and modify the total amount of DAI that can be transferred from the protocol using MIP14ā€™

I actually quite like this idea. MIP14 was always planned to be a generic fallback to be used when a more specific process doesnā€™t exist. Putting a cap on how much it can be used seems like a good way to encourage people to propose better processes for specific cases.

Other changes just seem like generally good inclusions.

Maker Relay Ep 11
#4

This is really good/helpful feedback! Will update Soonā„¢

1 Like
#5

I updated the MIP with @LongForWisdomā€™s suggestions and submitted a new PR

Changes:

  • Included feedback period of 4 weeks with a frozen period of 1 week for adjustments to the Transfer Ceiling

  • Add ā€œtotal DAI Processed by MIP14 to dateā€ to the historical transfer list. This will serve as the ā€œrunning totalā€

  • Updated MIP14c4 summary

  • Added Transfer Ceiling analysis section to the MIP14c2-sub-proposal template

Wondering:

  • Would it make sense to flip the order of 14c3 and 14c4
  • Is there a better place to put the ā€œrunning totalā€

Thanks!

p.s. learning github = :angry:

3 Likes
[Signal Request] Structure for MakerDAO Finance and Human Resources
#6

Itā€™s not an easy thing to learn, but imo itā€™s worth the investment.
Day to day frustrations disappear at some moment, then itā€™s magic :slight_smile:

1 Like
#7

First of all I think you need to explain what the Feedback Period and the Frozen Period is. And why are these periods so long? Nobody in crypto has an attention span longer than a week so what these payments were intended for could be lost quickly.

#8

These are covered in MIP0. But to explain briefly:

Feedback Period: How long the proposal must be public before it can be formally submitted into the governance cycle.
Frozen Period: How long the proposal must remain unchanged before it can be formally submitted into the governance cycle.

The length here is from the original proposal. The idea being that the more money someone wants to spend outside of other, more specific processes, the more discussion it needs to have. Keep in mind that this is intended as a fallback mechanism. For regular and expected expenses, I expect us to develop more focused and efficient process for distribution of funds.

1 Like
#9

I agree. Can we vote on these feedback periods? 4 months to transfer 100k seems excessive, especially once we scale. Perhaps if I understood what the ā€œfocused and efficient process for distribution of fundsā€œ was going to be it would make more sense.

#10

In practice these can overlap, so its three months. Potentially we can change the thresholds so itā€™s faster to move 100k.

For this Iā€™m more referring to repeating and expected expenses, funding domain teams, potentially paying for SourceCred. Stuff that has been agreed beforehand and so can have less stringent requirements for discussion.

1 Like
#11

I think all comments and questions have been addressed, so this will be Formally Submitted in the October governance cycle @charlesstlouis :slight_smile:

Thank you all for the comments and feedback!

4 Likes
[Agenda/Discussion] Scientific Governance and Risk #113 - Thursday, October 8 16:00 UTC
#12

Could you detail how the protocol currently allows that? Iā€™m especially curious of the latter part ā€” avoiding dilution after FLOPs. If true, this is a grave vulnerability in the protolcol.

#13

There is a function that can be called in an executive vote called suck that allows governance to take DAI out of the surplus buffer, even if there isnā€™t enough DAI in the surplus buffer.

Pretty sure itā€™s also possible for governance to directly mint MKR.

These arenā€™t vulnerabilities anymore than governance attacks generally are a vulnerability.