[Signal Request] Compensation Bridge for Delegation Contract Migration

@PaperImperium is transitioning to @GFXlabs. Mirroring this transition, at the time of writing, the old delegation contract still has 8,506.43 MKR delegated while the new delegation contract only as 5.02 MKR. This transition alerted me to a shortcoming in the proposed delegate compensation MIP, but the problem will affect all delegates, not just @PaperImperium. Currently, delegate contracts expire after one year. Delegates will need to create new delegate contracts and ask delegated MKR to migrate. This migration will cause volatility in delegate compensation. GovAlpha has clarified that delegates shall be compensated without reference to other delegates, even in this case when there is a clear intent to migrate.

I propose that a component be added to MIP61 to accommodate delegate contract migration:

In the event that a Recognized Delegate intends to migrate from one delegate contract to another, a special procedure is available to reduce unpredictable compensation. The delegate must inform governance 7 days in advance of the migration effective date and which contracts are affected. The new delegate contract cannot already be involved in a migration (e.g., two delegates merging into one). During a 15 day interim period, the old and new delegate contracts are regarded, for the purpose of compensation, as referring to the same entity and compensation calculated using stats from both the old and new contracts. For example, MKR weight will be obtained by the sum of the MKR weight of the old and new contracts. Participation and communication stats will register the most favorable stats considering both the old and new contracts.

Amend MIP61 to allow for a migration period between delegate contracts
  • Yes
  • No
  • Abstain

0 voters

This poll shall be active for two weeks, closing on Dec 02.

If ‘Yes’ has more votes than ‘No’ then MIP61 shall be so amended.

1 Like

Something similar needs to be done on the rollover after one year when a delegate contract needs to get replaced.

I don’t think in this specific case it is necessary though.

Huh, how would this not apply to the 1 year rollover?

Why did you vote No?

You mean the current GFX transition? This signal request won’t help the GFX transition because the signal request won’t even have a result for two weeks and that’s more than 15 days after the GFX migration.

Uh well… Short sighted. Good that polls run for some time. Thanks.

I actually believe the rollover period should be longer. Most delegators are not able to react within 15 days. Maybe a month?

1 Like

I am okay with 30 days. Can a GovAlpha team member weigh in? @mkrorbkr ?

I think this is an important issue, but I voted no because I think this is too complicated and moves us towards more human involvement by core units in controlling the delegates. IMO the delegates need to be separated as much as possible from the core units and their compensation and other characteristics should be automated as much as possible.

I’d rather just remove the 1 year time limit and think about other solutions that can deal with problem the 1 year limit was created for.

2 Likes

@mkrorbkr is writing to address this signal as a whole, but I wanted to add some insight to Rune’s comment in the meantime.

So the one year limit was quite intentional. Since it’s a permissionless system, there’s a good chance that we might lose touch with either the delegates or the person delegating in a year;s time. By having the expiration date, it helps close the gap and make sure that people who delegate are reevaluating their decision at least once a year.

Not having an expiration date could lead to a situation where there is a large amount of MKR stuck on a hat with no way to move it. It helps mitigate the “bus risk” of a delegate not being able to move the vote themselves, without being too burdensome on the delegate or the people delegating.

This time frame could be adjusted, but I would causion against getting rid of it completely.

1 Like

@psychonaut there are a couple of points here I would like to address.

MIP61 remains in RFC and as such does not require a Signal Request to change, this is what the RFC period is for! You can insert that component into MIP61 now if you like without a Signal Request.

The suggestion to start a Signal Request in the previous thread was to cover a one-off payment to GFXlabs for the specific instance of PaperImperium moving from one Delegate Platform to another. It is still possible for a Signal Request to take place to allow this. I’m happy to assist in writing it if you would find that helpful.

The 12-month expiration on delegate contracts has been addressed by @prose11 in his post. As I have previously stated I do think that is a different situation to this and should be explicitly covered in MIP61.

1 Like

Oh, let GFX care about that if they want. I’m just trying to address the general issue.

I’m closing the Signal Request.

1 Like