Open Sourcing Our Token Delegate Program

Crypto is about removing gatekeepers. It’s this property that differentiates it from traditional web services, and allows it to remain open, neutral, and fair. And yet, crypto protocols do not spring into existence fully formed. They evolve towards this state over time, with control shifting outward as the network scales upward.

As this process unfolds, a new set of “protocol governors” emerges to take the reins from the original development team. Done properly, this new community is incentivized to act in the protocol’s best interest and is diverse enough that competing interests can balance one another out. This allows the protocol to remain neutral yet nimble; resistant to arbitrary change and yet amenable to necessary upgrades. 

The end result is an open protocol sitting outside the control of any one person or company, continuing to run as designed and remaining open to anyone who wants to use it. A difficult feat to be sure, though we’ve seen a number of leading protocols execute this transition already, with many more on the way.

As stakeholders in many of these networks, our goal is to help facilitate these transitions in whatever way we can. We’ve discussed previously a few ways we look to do so, but wanted to expand on one that we think is particularly effective: token delegation. 

On its face, delegation refers to the process where a token holder transfers their on-chain governance rights to others. More fundamentally though, delegation is a way to expand the set of participants who have a meaningful say in the governance process. And when it’s done effectively, it’s ultimately a way to seed the development of a higher-quality governing body over the long term. 

To truly unlock these benefits though, a “strong” form of delegation is needed. One that not only reduces surface-level concentration, but that also enhances the quality and diversity of the governing body. And perhaps most important of all, one that empowers each delegate to vote independently from the token holder, in whatever way they see fit. 

Over the last year we’ve built a delegation program around these exact principles. We’ve used it to delegate well over half of our voting power in protocols like Compound, Uniswap and Celo to a broad network of qualified delegates. These include: leading non-profits like Kiva and Mercy Corps; global businesses like Deutsche Telekom; crypto startups like Gauntlet, Argent, and Dharma; university organizations like Stanford Blockchain Club and Blockchain at Columbia; and up-and-coming community leaders like Getty Hill.  

We’re excited to share this program with the community and to open source all of its component parts. These include: 

• Best practices for token delegation
• Criteria for assessing delegates
• Legal mechanics and template docs
• Current a16z delegate network 
• Ideas for future improvement

Our hope in publishing these resources is that they can be useful to a wide variety of community members, including developers thinking about protocol governance, token holders looking to delegate, individuals or teams looking to become delegates, and more. If that’s you, please reach out – we would love to hear your thoughts and find ways to work together!

Best practices for token delegation

Over the last year we’ve worked with dozens of delegates across a number of leading protocols. Below are some of the best practices that we’ve identified throughout that process and think are valuable for others to consider.

Delegate early. Delegation can be valuable at any point in a protocol’s lifecycle. But it’s perhaps most impactful during the early stages, where a protocol is live but the native token is not yet broadly distributed. During this period, delegation is valuable for a few reasons. First, it can accelerate the distribution of governance power ahead of the pace dictated by the token emission schedule. This is especially important in protocols with long distribution cycles, where it might take several years for a governance token to disseminate broadly throughout the community. In these cases, delegation helps to increase near-term engagement by giving more participants a say in the process. It can also help foster the growth of a higher-quality governing body over the long term (more on that below). Given that these effects compound over time, it helps to incorporate delegation as early as possible.  

Elevate community leaders. Delegation provides a way to elevate community members who demonstrate early leadership in governance. These tend to be active users who understand the protocol and want it to grow, but otherwise lack sufficient tokens to participate meaningfully. We’ve seen many examples of this to date, where an individual or small team demonstrates leadership, earns token delegations, and uses those tokens to advance meaningful upgrades to the protocol. This, in turn, begets further delegations, upgrades, and so on, creating a virtuous cycle. Identifying these types of leaders from within and elevating them through delegation inures to the long-term benefit of the protocol. 

Recruit outside perspectives. Delegation provides a tool to incorporate new perspectives into a protocol’s ecosystem for the first time. These are often individuals or groups who are interested in crypto, and who bring valuable and unique skill sets, but have not yet had a chance to get involved. Since delegation requires little or no upfront cost on their part, it provides the all-important foot-in-the-door, which is typically all they need to start contributing. We’ve seen this first-hand in many cases, having delegated to a number of nonprofits and student organizations, many of which have since emerged as leaders in their new governance communities. This helps to increase diversity both within protocol governance and across the crypto ecosystem more broadly. 

Ensure delegate independence. Delegates must be empowered to vote independently from the token holder. This is an essential property for any well-designed delegation program. At a minimum, this means that the token holder should not attempt to influence or dictate its delegates’ participation in any way, either explicitly or implicitly.  We recommend taking this even a step further, with the token holder committing to maintain its delegations for some minimum period of time, with the ability to revoke early arising only under very limited circumstances (e.g. continued non-participation in votes). There are likely additional ways to build this concept in further, but in general this type of mechanic gives delegates assurance that they can vote as they see fit. 

Provide ongoing transparency. As delegation becomes more commonplace, it’ll become increasingly important for token holders to provide ongoing transparency into their delegate networks. This provides the community with visibility into the relevant parties, the terms of the underlying delegations, their relationships to the token holder, and more. It will also allow the community to benefit from further iteration on these mechanics by opening them up for public review and comment. We’re committed to maintaining this type of transparency in our own program going forward, and encourage others to do the same. 

Criteria for assessing delegates

When we evaluate potential candidates, we assess them against a number of key criteria. In general, these are designed to identify delegates who we believe would enhance the governing body in some meaningful way, and will go on to become long-term leaders within the community.  

We’ve posted our full assessment rubric here, which we’ve used to score all of our existing delegates. In general, we focus on the following areas:

• Commitment to the protocol. What is the candidate’s level of commitment to the protocol and its governance?
• Subject matter expertise. What is the candidate’s background and how does it qualify them to participate?
• History of engagement. What is the candidate’s history in terms of community engagement, and how are they generally perceived publicly?
• Absence of conflict. Does the candidate have any outstanding conflicts of interest with the protocol, or any ways they would benefit from the protocol’s failure?
• Alignment with protocol’s success. Is the candidate positively aligned with the long-term interests of the protocol?
• Independence from a16z. Is the candidate fully “arm’s length” from a16z to ensure independent voting post-delegation?
• Impact on decentralization. Will delegating to the candidate help further the decentralization of governance power in the network?
• Diversity of perspectives. Will delegating to the candidate increase the overall diversity of perspectives within governance and help to avoid groupthink?
• Sense of overall stewardship. Does the candidate embody the ethos of stewardship and believe in the protocol’s underlying mission?
  

We score candidates on a 0-2 point scale for each category (based on the full question set included in the rubric), and generally look for a minimum score of 70% or higher in order for candidates to advance. As you can see from the chart below (which shows our current Uniswap delegate scores), there are many different ways to arrive at a passing score, with no single background or profile required.  

Legal mechanics and template docs

For candidates who meet the bar, we enter a brief agreement that lays out the basic terms of the delegation. We’re posting our template agreement here. As with the assessment rubric, this is the template we use for our existing delegates. 

Below are the key terms we include, as well as our rationale behind them:

• Participation. We ask that delegates stay informed and participate in a manner that they reasonably deem to be in the best interest of the protocol. Beyond that, they are free to participate however they see fit.
• Delegation Amount. We look to give each delegate enough tokens to have a meaningful impact on governance, by some relevant measure (e.g. enough tokens to introduce a proposal, for example).
  
• Reimbursement. We give each delegate a small fee to ensure that all of their expenses are covered. These are in all cases a de minimis amount ($500/month or less) and are designed to defray things like gas costs incurred in voting and submitting proposals.    
  
• Term and Termination. We commit to maintain the delegation for a minimum period of time (at least six months), with the ability to revoke only arising in very limited circumstances. Beyond those, we cannot revoke the delegation during the term, even if the delegate votes against us in every single vote. This helps to ensure that delegates are empowered to vote independently and in whatever manner they see fit.  
• Renewal. At the end of the initial term, our delegations automatically renew unless the parties agree otherwise. 

Once a delegate is onboarded, they are free to participate in governance however they see fit. We check in with our delegates occasionally, but otherwise they are fully independent from us after we make the original delegation.

Current a16z delegate network

Below is a breakdown of our current delegate network for Compound and Uniswap, including by delegate type:

While our delegate network has grown and diversified since we first introduced the program earlier this year, we are still in the very early days. We look forward to seeing an even more diverse ecosystem of delegates emerge over time. Let us know if that might be you!

Looking ahead

Ultimately, we are strong proponents of delegation and believe it has an important role to play in protocol governance. Our hope in publishing this framework is that it can serve as a useful starting point for others who are beginning to think about delegation and how to incorporate it thoughtfully. To that end, we encourage the community to freely use this framework, modify it, critique it, and ultimately offer feedback to improve it. 

On our end, we plan to continue building it out in a few key respects. First, by continuing to diversify the types of delegates we work with, both within the categories listed above and across new ones. If you are interested in becoming a delegate, please reach out! Second, by implementing it across a number of new protocols that allow for on-chain delegation. For developers and community members thinking about this decision, we would love to hear your thoughts and work together. And third, by incorporating feedback and ideas from the community to improve our framework and enhance it further, so let us know what you think!

###