MKR Holder’s Guide to Delegation

Five Key Points

  • Trust
    Delegation is an expression of trust of the MKR Holder in the delegate.

  • Incentives
    Examine your delegate’s incentives, these are not solely monetary, these are not always permanent.

  • Recognition
    Recognised Delegates are safer than Shadow Delegates (but not by much).

  • Balance
    Be aware of the checks on power among delegates and Core Units. Having only a few large delegates is a risk. Delegation to Core Unit personnel is not advised by GovAlpha.

  • Cost-Benefit
    Responsible Voting > Responsible Delegation > Apathy > Irresponsible Voting > Irresponsible Delegation. Responsible delegation is much, much cheaper than responsible voting and almost as good.


Trust has taken on a bad name in the crypto-space. Oftentimes this is for good reason, nevertheless, trust plays a key role in life and human interaction. Trust comes into play heavily in delegation.

Delegation is an expression of trust from the MKR Holder to the delegate

The fundamental trade-off made by MKR Holders when delegating is to benefit from an increased efficiency of governance, at the cost of trust and centralization. These costs are unavoidable, though they can be minimized by delegating responsibly (more on that later).

Ultimately the Maker Protocol (and the DAO) needs to have efficient enough governance to operate. If Maker cannot operate, then the MKR token will lose value. Likewise, if delegates collude and attack the Maker Protocol, then the MKR token will lose value.

MKR Holders must create a balance between these two extremes that results in an operable protocol while minimizing risk of governance attack.


The word ‘incentive’ has taken on a narrow meaning within the crypto-space, however this meaning (primarily financial) has led to the exclusion of a myriad of other motivations that humans hold. Humans are both dynamic and varied in their motivations, and we should expect the same from delegates.

Examine your delegate’s incentives, these are not solely monetary, these are not always permanent.

The table below shows a selection of incentives that delegates can have. It is not meant to be exhaustive (people are complicated) but it covers the factors that GovAlpha could come up with.

Source Incentive Type Stability Governance Controllable
Holds MKR Extrinsic - Financial Unstable No
Holds vested MKR Extrinsic - Financial Stable No
Paid percentage of Maker Protocol revenue Extrinsic - Financial Variable Yes
Maker Protocol is primary employment Extrinsic - Financial Variable Yes
Being a delegate delivers status + prestige Extrinsic - Reputational Unstable No
Values delegate work Intrinsic - Character Variable No
Maker Protocol benefits society Intrinsic - Character Variable Variable
Morality Intrinsic - Character Variable No

There are several items of note that can be taken from this table:

  1. Very few incentives are verifiably stable.
  2. Governance has control over some incentives.
  3. The character of the delegate is important.

To simplify this somewhat, if you are considering delegating your MKR. Ask yourself the following questions:

  • Does this delegate hold MKR? Is it locked for the duration of the delegate contract lifespan?
  • Is this delegate paid by the protocol or an external actor (If the latter, who and what is their objective)?
  • Is this delegate reliant on the Maker Protocol for their own financial stability?
  • Does this delegate have a reputation on the line? Do they care about their reputation?
  • Does this delegate enjoy being a delegate? Have they reliably enjoyed it in the past?
  • Does this delegate believe the Maker Protocol is a public good?
  • Does this delegate display strong morals? Are they a trustworthy person?

Many of these questions are hard to answer, hence the requirements for trust:

  • …that the delegate is accurately representing their incentives.
  • …that you have accurately judged the delegate’s represented incentives.
  • …that the delegate’s incentives are stable over time (or that you will be engaged enough to manage changes).


The split into Recognised and Shadow Delegates has a few advantages. One of which is the integration of reputational collateral for the Recognised Delegates. By requirement, they are publicly known, this gives them an incentive to do a good job with any MKR delegated to them on pain of damaging their reputation.

Recognised Delegates are safer than Shadow Delegates (but not by much).

However, reputation is only one source of incentive alignment, it helps, but it is not a guarantee that a delegate is trustworthy.

By default, Shadow Delegates lack even this incentive alignment. GovAlpha recommends that MKR Holders consider delegating to a Shadow Delegate only under the following circumstances:

  • The Shadow Delegate has verifiably locked more MKR than you plan to delegate to them for the duration of the delegate contract lifespan.
  • You have a personal or professional relationship with the Shadow Delegate that the Shadow Delegate values.
  • There are no Recognised Delegates.
  • MKR is concentrated in the hands of too few Recognised Delegates.


The distribution of power within the Maker Protocol is governed by a moderately complex web of checks and balances. By and large, the disengaged MKR Holder does not need to worry too deeply about this. That said, there are a couple of places where this impacts delegation.

Be aware of the balance of power among Delegates and Core Units.

There are two main points to consider here.

#1 Delegate-Delegate Balance

The more delegates that have a say in the passing or not-passing of proposals, the better. If your favourite delegate already has a large amount of MKR delegated to them, consider delegating to a different delegate.

The delegation contracts support MKR Holders splitting their MKR between multiple delegates. This may be advisable to mitigate the risk posed by any individual delegate.

In the longer term, GovAlpha would like to see a community of tens of delegates such that centralization risk is effectively mitigated.

#2 Delegate-Core Unit Balance

Delegates and Core Units are a check on each other’s power. Delegates can propose (and potentially vote through) whatever they want, however, they require experienced personnel to construct proposals. Further, any decision that impacts the Core Units requires their implicit consent to accept that impact.

On the other hand, delegates can refuse to vote through proposals created by the Core Units, if they do not believe they are in the interests of MKR Token Holders.

In the worst case, a complete combination of the two groups means that a single collection of entities is responsible for both implementation and ratification of changes.

Here are some examples of potential negative outcomes that could result from the combination of Core Units and Delegates:

  • Core Units proposing and approving their own budgets.
  • Delegates constructing and approving their own remuneration.
  • Reduction of transparency to the community and MKR Holders.
  • Core Units with attached delegates receiving a disproportionate amount of budget relative to those without representation.
  • Centralization of control within the DAO.

All this being said, GovAlpha is aware that exceptional individuals and circumstances may exist, and we are aware that no rule can be enforced here due to the permissionless nature of the delegate contracts.

We leave it to MKR token holders to judge when and if it is appropriate for them to delegate to Core Unit personnel.


The cost-benefit calculation to governance of the Maker Protocol has never been particularly favourable to MKR holders. There is much to govern, and much to keep up with. Delegation represents a long-awaited improvement to this calculus.

Responsible Voting > Responsible Delegation > Apathy > Irresponsible Voting > Irresponsible Delegation.

Delegation increases the variability of outcomes relative to individuals voting. The chance for greater governance effectiveness exists, but it is balanced by a greater amount of centralization and collusion risk.

With individuals voting, there is less chance for effective governance, but also less chance for malicious governance, with delegation, there is a greater chance for both outcomes. For this reason, we view apathy as preferable to irresponsible delegation.

Responsible delegation is much, much cheaper than responsible voting and almost as good.

That said, responsible delegation is much, much cheaper than responsible voting, and almost as effective.

To aid in cost-benefit judgments, here is our estimate of the cost-to-the-individual in terms of responsible delegation to one or more Recognised Delegates. Note that delegate contracts currently expire every year. So these should be considered annual costs:

  • Spend a few hours reading over the Recognised Delegate platforms, figure out which delegates care about what you care about. Watch ‘Meet Your Delegate’ recordings if you prefer video.
  • Spend 30 minutes thinking about incentives and trust in relation to your chosen delegate(s).
  • Take note of the metrics surfaced by GovAlpha on the ‘semi-official’ voting platform.
  • Spend gas to delegate your MKR to your chosen delegates.
  • Spend 30 minutes a month to check in. Check your delegate is still active, check their metrics are still good.

Ineffective or participation-starved governance will kill the Maker Protocol over the long-term just as surely as governance attacks will in the short term.

If you are holding non-trivial amounts of capital in the MKR Token, GovAlpha believes you should seriously consider delegating responsibly.


Open to any feedback here. If you think there’s something I’ve missed please let me know. I’d love to make these docs as good as possible.

Sorry I have no specific feedback for improvement, but just want to say: very impressed with this guide. It is short, hits on salient and nonobvious points, and contains a lot of, dare I say, wisdom.


I’d like to see the Balance point explored more fully.

I can see that a complete overlap would be a bad thing, e.g. CUs being able to approve their own budgets. But that would imply a high degree of centralisation or collusion.

I had always assumed that (some) CUs would act as Delegates, and the Balance would be down to MKR holders limiting the amount of MKR delegated to them, just as they limit the amount delegated to other individuals who become too influential.

I know this is a complicated question, but I would say the answer lies in cautious balance - i.e. having some Delegates attached to CUs - rather than discouraging it entirely. After all, CU members are likely to hold MKR, to vote, to be interested in the health and future of the Protocol, and to know MakerDAO inside and out. Who better to make critical decisions about it? And doesn’t it make sense to align interests as closely as possible?

I’d be interested to hear others’ take on this, including those in CUs, proposed Delegates, and ‘regular’ MKR holders.

1 Like

Yeah, it’s a little abbreviated since it’s one of five points here and not the main focus.

I think you’re right, and this will happen. I think it’s important that MKR Holders understand the potential downsides to this though.

The danger with this is that it has the potential to start an arms race that forces all the CU’s to put up delegates. Imagine that we have two Protocol Engineering Core Units, both of whom are wanting to increase their budget by 50%. If one of those units has their own delegate - and the other doesn’t - then they have an advantage as governance makes that decision that they shouldn’t necessarily have. So now the other Core Unit needs their own delegate as well.

We shouldn’t want to force Core Units to be political, that isn’t why we have them, and it steals their resources and focus from their primary role.

For what it’s worth, we did explicitly call out in the post that there could be exceptions where this is warranted, either on an individual level, or in specific circumstances. Ultimately it’s up to MKR Holders, as you say.

If anyone wants to write a piece about the advantages to delegation to CU folks, you’re more than welcome, and I’ll make sure it’s hosted prominently alongside GovAlpha’s PoV. We’re not attempting to force the issue, just to make it clear why we believe it’s a bad idea.

1 Like

Very valid point. On the other hand, I’d trust PE to make highly informed decisions on fees and other Protocol parameters. One solution might be to depoliticise it by discouraging CUs from voting in budget decisions. This is just a variation on the theme of avoiding conflicts of interest.

I also expect some Delegates to form close alliances with particular CUs, as they work with them, campaign, and shape their agendas. That’s not quite the same as a CU voting for itself, but it poses similar risks.

1 Like

This is an excellent resource for anybody considering delegating their MKR. It posed many interesting questions and points of view I have not directly considered.

With regards to shadow delegation—are there any safeguards against an anonymous minority gaining a majority voting share? I don’t have any reason to think this would happen in practice, just poing a theoretical question.

1 Like

The delegation contract is permissionless so there isn’t anything to stop this from happening at the technical level.

At the social level it’s quite dangerous to the stability of the MKR token so holders would be incentivized to take counter action.


A post was split to a new topic: Delegates Actively Supporting Clean Money?