Just wanted to add a short technical perspective.
First, I think these threads are a great way to work through ideas around delegation, its benefits and it’s disadvantages. Perhaps by the end of this we can at least say, “If you’re going to delegate your vote, this delegation model is the gold standard.” To that end, keep the discussion coming.
However, to focus the discussion a little, I want to stress this fact: there is no technical way to stop vote delegation with our current system. That is, even if we are repulsed by the idea, or think it would make our ecosystem unhealthy, we cannot stop it from happening. With this condition in mind, I believe we are best to inform MKR holders that want to delegate what they should be looking for in a delegation system.
Some ideas (some solve the same problem):
- Only allow a delegate to be in control of some multiplier of their stake. E.g. if a delegate has 10 MKR, only allow and additional 1x, 2x, or Nx stake to be delegated. This would result in total values of 10 + 10 = 20, 10 + 20 = 30, or 10 + 10*x respectively.
- Lock the delegate’s stake up for some timeframe to ensure their MKR is accountable to the results of their vote.
- Allow a delegating user to withdraw their delegation at any time.
- Burn or slash the delegate’s MKR if they verifiably vote against a known model.
If you reply to this list with ideas, I will try to keep it up-to-date. We may want to spin a thread off to discuss the merits of each option at some point.
My current interest in this is centered around the idea of risk teams (or funds) insofar as we may decide to delegate our MKR with a risk team based on their models, voting record, and results. I was particularly captivated by the idea of using a PID controller to drill down on the peg, and I would love to delegate some of my MKR to a PID controller that successfully accomplished this goal.
I share the centralization of power concerns that some of you have expressed in the same way that I am concerned about the effect of gravity on me when I fall: both are of concern, but are immutable laws of the system we’re operating within. To this end, let’s focus on best practices for such a delegate system and hope that MKR holders will not delegate unless such a system possesses those ideal properties. If we find a good mix of healthy properties for delegation we may be able to make using a system with more relaxed constraints as appalling as sending one’s credit card over HTTP or logging into a remote system with telnet.