MIP 54: DssVest

It’s possible, but the DAO is moving to streaming payments generally by way of the Keg, so this seemed like a congruent solution enabled by the technology.

That’s an alternate solution, and one that requires that 1) the MKR exist, and 2) the MKR is managed. This was more of an issue before the Foundation transferred funds to the DAO, but it’s also somewhat messy, considering that not all MKR allocated will be paid out and that unpaid MKR would need to be recaptured (and probably burned) anyways. The ability to mint and burn MKR as needed is already a core component of the system that allows for clean accounting of the supply.

The tokens are minted at the time they are claimed, so they don’t exist until a user initiates the transaction. I’m not a lawyer and this is not financial advice, but I think there’s some room for a different interpretation here.

1 Like

You can mint and put into it, that gives you a better security over the contract and over the found to be distributed. I just noticed it as yearn contract is doing it.
You can image a scenario where governance has to migrate the MKR contract. Also as I said it is more difficult to burn MKR from someone than deauth a contract for security reason as an example.
By doing that your contract is standalone vs depend of the MKR contract.

1 Like

Is it though? According the makers own website Maker only mints MKR when the Maker Protocol is running a deficit and the system debt exceeds a maximum threshold, MKR is created and auctioned for Dai in order to recapitalize the system

I understand it is more efficient from a programming stand point to mint/burn MKR on demand however I do have concerns that it goes against Makers original mission statement. I’m sure there are members in the community that would agree minting MKR should only be a last resort.

@alexis , we’ve chosen the above implementation because we believe it is the easiest and safest solution for MKR vesting. The alternative you suggest is possible, but minting the full amount upfront is not ideal because in many cases it may not be paid out in full. Likewise, in the current implementation, it is easier for either Governance or the Facilitator to remove the award if a person leaves. This eliminates any overhead for managing the burning of MKR, because it is only minted once it is claimed by the user.

@Zarevok , minting and burning MKR is a core component of the Maker protocol. When and how it is acceptable to mint MKR has indeed changed over time. We’ve recently seen Governance vote to mint MKR as an ongoing incentive for core units - if that is still up for debate, it’s probably worth a separate thread as this thread is specific to the mechanism for how to handle vesting.

3 Likes

FYI Submitting this MIP for Formal Submission into the June cycle.

4 Likes

Something I want to flag here: I would like to review how this proposal got from an approved mechanic to actually being implemented to pay out specific core units.

We’re now minting MKR for purposes other than backing the protocol and this decision has not been properly discussed. (Strictly speaking: we will mint MKR on the first vest.)

For example legal considerations have completely been ignored. Who made this decision and why was it accepted without second thought?

It came up in the thread about the foundation’s 84k MKR. And then the outcome was ignored and this was implemented anyway without approval.

In the future proposals like this should be flagged by @MIP-Editors because they don’t specify concrete governance actions.

The step from “this is a mechanic we can use” to “we’re using it now in specific cases” was a decision that has been taken without transparency.

This is like the difference between having the Vox module available as a tool and actually enabling it. We need to understand the line here that was crossed so that it doesn’t slip under the radar the next time.

10 Likes

Thank you for bringing this up @wouter. I feel MIP54 could need another round.

5 Likes

There are two warning signs that I ignored myself:

  • I remember reading this MIP and thinking “So this is a module… and then what? What are we actually approving?”

  • The decision to enable it wasn’t really kept secret, which is why I think it was an honest mistake. The question was asked if SES wanted to be paid out with it and our reaction was that that would require us to publish a new budget MIP. We should have pushed harder to insist that other core units update their budget MIP for it too. Part of the reason was that the focus was on Dai payouts. I didn’t fully realize at the time that we’d be minting MKR now.

2 Likes

If nothing else, I definitely want us to try to use the 84k MKR on hand before minting new MKR. Should MKR be determined a security, the Foundation is on the hook for any that has been minted/issued to date. This probably(?) gives the DAO more protection about issuance regulations.

It also makes me think when we’re ready to burn again that we should be holding onto it.

Yet another area that some professional legal advice would be helpful :sweat_smile:

5 Likes

The proposal itself is inconsistent:

This recognizes that there is a decision that still needs to be made.

This one assumes minting anyway.

2 Likes

Is it possible to put MIP54 up for a revote, or do you feel for a discussion first? What is your take on the next step here?

1 Like

Three steps I would suggest:

  • Reopen the discussion where the MKR for retention bonuses should come from. There’s no need for immediate action because the first cliff vest is still many months away. Confirm a decision through a proper vote. I don’t know if MIP54 should be replaced… there is no real governance action described in it, so it doesn’t really mean anything beyond a vague approval of the general mechanic.

  • Reconcile the current situation with the decision: the deployed DSSVest modules can be replaced or upgraded (depending on the technical details) if the outcome isn’t in line with the deployed instances.

  • In parallel: identify how this could have been avoided and put some measures in place to improve our governance process.

This will be a win in the end if it means our governance processes will become more resilient and better at detecting these issues. It’s thanks to the transparency that we have already in place that this could be detected in time.

3 Likes

The vesting parameters (timeframes and core unit amounts) were voted upon and approved as part of the core unit budget MIPs. DssVest was then separately voted upon as a mechanism to apply the aforementioned vesting parameters. Looking at the past 9 months:

  1. MIP42: Proposed Compensation Addendum in January 2021 sparks conversation for a DssVest-like mechanism.
  2. Know your MIP Community Call: MIP48 Keg Streaming Payments Module discussed on February 5th
  3. Core Unit budgets (including MKR vesting amounts) were submitted as part of the core unit mandate (e.g. 3rd of March for PECU
  4. Maker Foundation confirms it will give 84k MKR to Governance
  5. Successful core unit budgets were subsequently approved, while the precise mechanism was left undefined on purpose due to unclear Governance intentions regarding Dev Fund MKR. E.g, should there be a cooldown period or should Governance burn the 84k
  6. Community review of Keg implementation revealed that DssVest was optimal for distributing any ERC20. Keg implementation was dropped in favour of DssVest.
  7. DssVest was then proposed as a mechanism to support DAI and MKR payments in May as part of MIP54 in order to support MIP40 submissions.
  8. Ratification Poll for DssVest on June 14th, with 39 voters
  9. 26th July: ABDK audits are completed on DssVest
  10. DssVest Executive Vote delayed due to other more pressing executives (Centrifuge Asset Onboarding, 6s Updates, and Reduced Vault Ratios)
  11. DssVest was put forward for executive vote approval on September 3rd.
6 Likes

Thanks for the overview, Derek. DssVest as presented here was definitely voted in. I’m not contesting that.

The question is: when was the decision made that the deployed module instances should mint new MKR upon vesting as opposed to take from the 84k? Or potentially via an alternative.

2 Likes

Based on the discussions in this signal request I’d argue that a lot of the votes against burning the 84k MKR was in fact to avoid MKR minting.

5 Likes

The intention of DssVest from the beginning was always to mint new MKR.

Throughout the coding of DssVest, Governance had remained unresolved on what to do with the 84k MKR.

If Governance decides to use part of the 84k MKR for vesting purposes then it can choose to point DssVest towards that MKR instead of minting.

4 Likes

I’ll write up my analysis next week of how we can avoid this in the future.

It’s not my intention to pick on anyone in particular or the people who have been involved with this; as I said: I have ignored previous opportunities when I should have spoken up, myself. I think this case just illustrates a few improvements that can be made to the MIP framework.

The fact of the matter is that it was my understanding that this MIP was going to be followed up with another one defining the specifics. Presumably amendments or replacements of existing MIP40s. Or I would have argued against it, for the reasons that I outlined here.

To a large extent this is because of how the MIP is phrased. It presents a mechanic without explaining how and when the mechanic will be applied and with which parameters.

Furthermore it states:

Good. The one in bold is the one I would go for.

It does not state, which it ideally should have:

  • While it supports other mechanisms, when it gets approved it will be implemented by minting MKR. (Why does it mention the other options then?)

  • When this MIP is approved, it will be applied retroactively to earlier approved MIP40s without additional governance approval.

  • When it gets approved, this is the list of CUs and these are the parameters that will be applied.

It isn’t a big issue. No irreversible actions have been taken. The MKR hasn’t been minted yet and the deployed instances can be replaced, should governance decide to do so. And we’ll be a little wiser.

I assume this would require a redeployment of the existing instances?

4 Likes

Why are we going to mint MKR (I’d vote against that ten tmes out of ten) when we have a treasury of 84,000.01 MKR just sitting there? That makes no sense at all.

To the extent we have to re-work MIP 54 to permit use of treasury rather than minting (which is nearly always a bad idea save for debt auctions), I’ll support that 100%.

2 Likes

I’m not a lawyer, but this distinction between minting and transferring MKR reminds me of a paper I looked at recently: ON THE GENERAL RELATIVITY OF FISCAL LANGUAGE

Abstract

A century ago, everyone thought time and distance were well defined physical concepts. But
neither proved absolute. Instead, measures/reports of time and distance were found to depend on
one’s reference point, specifically one’s direction and speed of travel, making our apparent physical
reality, in Einstein’s words, “merely an illusion.”

Like time and distance, standard fiscal measures, including deficits, taxes, and transfer
payments, depend on one’s reference point/reporting procedure/language/labels. As such, they too
represent numbers in search of concepts that provide the illusion of meaning where none exists.

Governance Perspective on DssVest

Appreciate you bringing this topic up @wouter and I am (as always) open to hearing how we can communicate intentions and future results of votes more clearly. I will say from a Governance perspective it seems MKR voters had ample opportunities to ask for clarification or delay this process. It took several votes to get to this point (approving MKR packages for CUs without defined methods for paying that MKR, the approval of this MIP mentioning its intention to allow the minting of MKR related to vesting, and the executive itself that passed the vesting packages) and all were approved with relatively strong voter participation.

Options Available for Changing Course

Some people might feel strongly about the differences between minting new MKR and paying out with MKR in the Proxy. From the Governance side the differences are fairly negligible (MKR that wasn’t in circulation goes into circulation, being distributed according to budget MIPs approved by MKR voters). Anyone that does feel that the MKR in the Proxy should be used instead of adding to the MKR token supply has several options to change course at this juncture, ranging from putting up a signal request to crafting a more intensive MIP.

For instance, a proposal could be made to burn an equivalent amount of MKR from the Proxy for every MKR minted from the current DssVest implementation. To prevent future votes needing to pass to follow through on this, someone could instead propose to cancel the current MKR vesting streams and instead transfer MKR from the Proxy over to new DssVest streams, utilizing the contract’s ability to create streams for any ERC-20, provided the tokens are available. A more cumbersome solution could be to require an executive vote for every instance of MKR dispersal or minting, though the ramifications of this would need to be carefully considered.

Anyone can propose these solutions if they find them particularly attractive and as a Governance Facilitator, it would be my job to make sure they are considered and given the proper Governance life cycle.

Background and Governance Philosophy

Currently, we have had several votes and discussions that lead up to the current implementation being used. I will try to find the link, but I recall asking @Derek during a G&R call shortly after PE’s budget got approved if we would be minting MKR for their vesting package and how that would be approved. IIRC the response was that a MIP would be submitted which is how MIP54 came about.

It’s also worth noting that DssVest is just a tool, intended to simplify the budget distribution process for the protocol. There are several ways we can use it, and for processes like this Governance seeks to find the intersection of what the Core Units would like and what the MKR holders approve. Moreover, with Delegation in place, it is easier than ever before for large amounts of MKR weight to seek direct clarification on what they are voting in favor of during an executive spell. It is likewise easier to organize MKR weight to change a current implementation, should the will to do so be present.

Takeaways/Reflections

There are some lessons to be learned here, and I particularly think it is important to reflect on the responsibility of MKR holders to know what they are approving. We make use of a large amount of labor to get each executive up for a vote, with conversations taking place 1 on 1 and in the public eye to ensure we accurately communicate what will change if spells are passed. I welcome input on how this can be done more effectively.

I believe there is an opportunity to utilize a slower cadence for executive spells to ensure proper communication and discussion over what is being put up for a vote. We do have to weigh this against the sometimes urgent nature of changes that need to be made, as there could be serious problems with seeking extensive amounts of discourse on the minutia of changes. However, we have nothing to lose when we are already planning ample lead time on non-urgent votes. I think aone concrete way to improve things will be to share repos and drafts with the community as they become available and will see how we can put this into practice for GovAlpha.

8 Likes