Right. With a liquid democracy one can delegate their MKR to a Delegate that has the best representation of their view for a certain subject/matter. As an example, one can delegate say to PRose for one Executive Cycle, and then in the next cycle—remove his/her MKR and Delegate it to say, Aaron—because his views are align with yours. Cool. Folks can jump ship whenever they feel their delegate is not up to par.
Be careful, little shrimps might end up in sushi!
Is anyone concerned that this could result in a concentration of voting power?
If delegators coalesce around a trusted delegatee, couldn’t the whole system be at risk if they go rogue?
Better the devil I know than the short seller I don’t
I believe you could undelegate if your delegator goes rogue. I assume there might be short term damage (and we should indeed think about how to mitigate that) but most actions could be reversed one executive vote later.
it will concentrate the power. but as long as that power can be undone by the owner without the delegates consent, the concentration increases efficiency and probably a good thing
One thing to keep in mind is that in a “delegate goes rogue” scenario, they need to maintain their majority stake on the hat for 2 days to have it go through (otherwise another hat could cancel the executive). In that time delegators are free to pull their MKR at any time. I don’t think this is a likely scenario, but even if it happens I think the chances of success are very small.
I am interested in being a delegate as well.
Also interested in participating as a delegate. I’m curious if anyone feels there could be a conflict from serving as a delegate while also working as part of a core unit?
I think it depends on the unit and the persons position within it. Generally I’d say non-facilitators are free to do whatever.
That said it’s probably best no one working for GovAlpha also serves as a delegate. I know Protocol Engineering want to avoid it as well on their end.
Yes, I agree with LongForWisdom–depends on the Unit–but for you @monet-supply you’re too special to the entire DeFi ecosystem to not have you as a Maker Delegate
I would be surprised if many CUs did not want to be involved as Delegates. Far from being a conflict of interest (in most cases - GovAlpha exception noted), it shows that the Units are committed to the security of the Protocol and want to further Dai and the Maker ecosystem. It shows aligned interests: they are maintaining/promoting Dai directly through their various activities, and supporting the Protocol via governance.
If community members don’t want to delegate MKR to a CU because they don’t agree with its stance, fair enough. But if a prospective CU says, “We’re doing xyz to help the DAO, but we don’t care much about governance”, then unless there’s a specific reason, it’s not a great look. I’d almost hope many CUs offered to become Delegates by default.
I’ve been thinking about this and I wondering if it would be a good idea to Ask MKR Token Holders to Nominate a batch of Delegates and allocate (Stake) their MKR to their Nominees based on an Election Algorithm. In other words, if I hold 1,000 MKR and I wanted to delegate them to say @Planet_X —I would interact with the Voting Contract and allocate (stake) my 1,000 MKR to him.
Or, what if I wanted to nominate 70% of my MKR to Planet X and 10% split 3 ways for the rest of my chosen Delegates—plus I think it will take 4 Transactions(I could be wrong)—wouldn’t it be better if we have an Election Algorithm that can make those decisions based on Randomness that will lead to EVEN distribution?
Let’s assume 55% of MKR Token Holders love PaperImperium because he’s super active and they don’t know much about Pantera, or they don’t Trust Planet X. There is the possibility the weights can be swung to one-side versus the other. Does that make sense?
Objective: Determine X, Y, and Z such that:
- The minimum backed Delegated MKR Stake is Maximize
- The total number of Delegated MKR is Maximize.
- The Variance of Delegated Stake is Minimized.
Are there any videos I can watch explaining how this will be implemented and how it will look for the person looking to delegate their MKR?
There might be differences but I think UNI already does delegated voting and I imagine Maker’s system will be similar.
Check out how it works for UNI here.
This is helpful! thank you
My personal opinion is that anyone involved with a core unit should not be a delegate. I have to be honest, your proposal made me question the “hard line” I’ve taken on the topic as you have so much experience and would clearly make an excellent delegate. But still, I think it’s a line that shouldn’t be crossed. I think there will be too many times where you’ll end up negotiating against yourself.
I like this idea as a social norm. It spreads out talent. Being a delegate could be regarded as a pipeline for recruitment into a core unit.
Yeah, I was thinking being a delegate meant not having a horse in the race. In other words, you are voting in an unbiased manner. It seems hard to be unbiased if you are in a position where you have to represent the interest of the voters and your own/core unit’s interest.
There’s a post coming very soon directed at Maker Holders, and it addresses this a bit. TL;DR is that it’s probably a bad idea to try to forbid it, but we’re recommending against.
In later versions of the UI, we may include a danger icon or something with a tooltip that links to the docs about it.