Jump Crypto: How to Ensure the Independence of Token Delegated Governance with Code?

Original authors: Nihar Shah, Joe Howarth

Original compilation: aididiaojp.eth, Foresight News

TL;DR

• While token delegation programs can achieve robust governance, the independence of token delegation is limited because token holders can revoke delegation rights immediately.

• For token holders with independence requirements, such as institutional holders, we recommend that token delegation contracts can embed explicit lock-up periods.

• We demonstrate this through the Maker contract, while adding other features, such as governance being able to bypass the lock-up period if decisions are mutual or if token holders trigger an emergency bypass.

Introduction

In the past two years, the concept of token delegation has become increasingly popular. Token delegation refers to token holders granting their voting rights on-chain to others, with major protocols including Maker, Compound, and Uniswap using token delegation to govern their communities. Token delegation enhances governance and fosters community growth, including student groups, non-profit organizations, and community leaders.

Delegated tokens have two special advantages. The most direct advantage is that it can make governance more efficient. Without a delegation plan, some community members may have little relevant interest or not enough time, yet they have to sift through dozens of proposals and understand complex governance schemes to participate in voting. Through delegation plans, some professionals can make more informed, consistent, and significant decisions. In many cases, representative democracy has advantages over direct democracy, and the crypto market is no exception.

Since last year, the second advantage of token delegation has begun to emerge: neutrality. For example, some token holders may have significant holdings and may also hold tokens in competing protocols; these holders may wish to commit to building a decentralized and fair community, and delegating voting rights is a way to ensure they are seen as maintaining neutrality.

The second advantage does not rely solely on token delegation programs to guarantee it; it requires special conditions that are independent of token holders. For instance, a16z's Jeff Amico articulated the principles of token delegation in his article, emphasizing the importance of "authorizing each representative to vote independently of token holders in any way they deem appropriate." However, most existing token delegation protocols do not enforce this independence, and in some cases, this independence may be deliberately undermined before key governance proposals.

This article provides a simple, code-based solution: by adding lock-up period functionality to the protocol, token holders cannot revoke the governance rights of their delegates during the lock-up period. Additionally, we create a reference case for this concept, along with some optional bidirectional non-emergency and unilateral emergency bypass features compatible with Maker's protocol.

Lock-up periods are not suitable for all holder-delegate relationships. For efficiency reasons, small token holders using token delegation should retain the right to revoke voting rights at any time, and the community can reshape the agency relationship between large token holders and the protocol by separating the two, allowing holders to freely authorize while delegates can vote independently.

Paradise Lost: Revoking Delegation

While token delegation is widely regarded as having high potential, it is not without criticism. Both theoretically and practically, token delegation programs can overlook norms regarding authorization, undermining the desire to establish sound governance.

For example, Chris Blec of DeFi Watch has been actively advocating for the clarity of choices and interactions in the delegation programs promoted by a16z. Blec points out that if governance proposals are approved solely by one or two holders, it raises questions about the relationship between voting representatives and token holders.

These risks are real; for instance, aside from Maker's Poll 819, the more widely known LOVE vote was primarily centered around the selection of a loan oversight body and the broader community governance discussion on decentralization versus efficiency. This proposal was highly controversial and intensely debated (it created a record for participation in Maker voting, which still stands as of this writing). Luca Prosperi documented the broader voting process, but mainly focused on the details relevant to token delegation.

This indicates that key governance proposals can bypass token delegation procedures. For example, Maker's founder Rune Christensen altered the proposal authorization during the delegation period, affecting the voting outcome. Although Christensen publicly opposed the proposal, he delegated nearly all of his MKR tokens. However, during the two-week voting window, he revoked the authorization of representatives who voted in favor or abstained and reauthorized those tokens to other representatives who had not voted. This redistribution seemed to be a tactic to mask the fundamental disagreement between Christensen and the representatives who voted in favor. Within three days after the voting ended, Christensen returned the delegation to the representatives who had voted in favor in the previous election. This pattern is illustrated below:

Legal Solutions

Token delegation programs need to become more robust. One solution is to ensure the independence of authorization and enforcement through legal contracts, such as committing to a minimum governance holding period in a16z's delegation program. This can mitigate the risk of token holders reclaiming governance rights if the representative's vote conflicts with their interests. More generally, it limits the pressure token holders can exert on their delegates.

This principle is enforced by placing legal contracts in a public Github repository. The key point of the legal contract is in Section 6, which states: "To prevent the case where the representative fails to fulfill their governance duties under this agreement, the initial term of this agreement shall be [N] months from the effective date, and the token holder may only terminate this agreement before the term expires."

However, legal mechanisms are a suboptimal choice. We do not doubt a16z, but those who follow in their footsteps may not be as noble. The enforcement costs of legal contracts are high and embed asymmetric power distributions, including opaque negotiations. In the hands of less diligent token holders, legal contracts undergo little meaningful scrutiny.

Thus, due to reliance on too many assumptions about transparency and enforceability, legal contracts may be the wrong mechanism for broadly expanding and enhancing token delegation programs.

Recommendation: Code, Not Law

This article proposes a simple solution: smart contracts instead of legal contracts. In other words, by embedding lock-up periods directly into smart contracts to protect the independence of delegates. This is highly transparent in advance, easy to enforce afterward, and most importantly, it is typically a straightforward technical implementation.

We demonstrate this using the Maker contract. Most of the core delegation logic exists in the VoteDelegate.sol contract, particularly noting the lock and free functions, which fully meet the requirements. Token holders use the lock function to bundle tokens and allocate their governance rights, and use the free function to reclaim those tokens and associated governance rights.

Some simple modifications can also be made. First, when calling the contract constructor, we define a variable named _lockupPeriod; second, holders call the initialUnlock function to trigger the unlock countdown; third, to check if the lock-up period is being adhered to, the free function must be slightly modified.

By embedding a lock-up period, the token delegation program becomes more publicly trustworthy, with the independence of delegates guaranteed by code rather than law.

Emergency Bypass Functionality

Of course, lock-up periods may not always be desirable, and we can modify the smart contract accordingly.

First, the delegate and token holder can mutually agree to end the delegation relationship. In this case, a bypass function can be provided, which can be implemented through a simple function called delegatorBypassLockup, allowing the delegate to relinquish governance rights without delay. (Note that the parameter isDelegatorBypassEnabled can enable this feature when the contract is launched.)

Secondly, there may also be emergencies where token holders unilaterally bypass the lock-up period, such as if the delegate acts in a highly irresponsible or hostile manner, though this situation would not occur frequently.

A good solution is to allow token holders to bypass the lock-up period by irrevocably burning tokens, which is easy to implement. When initializing the contract, the token owner sets an EmergencyUnlockBurnPercent value (potentially up to 100%). Then, the free function is modified to check if the token holder has chosen the emergency route. If so, it will only return the unburned token share and burn the remaining share. We show part of this logic here:

Complete Token Library

All function requests for the features and modifications discussed in this article can be found in the following public Github repository, which also includes all necessary changes to the Maker architecture. We welcome feedback and suggestions and believe that this contract is ready for production deployment.

Future Vision: Composability

Token delegation programs can become richer, and we believe that the composability of token delegation contracts will unlock the next wave of innovation. For example, what if representatives could delegate their voting rights to other representatives?

This relationship could make delegates more independent. For instance, token holders could delegate their tokens to a student group. In turn, the student group could delegate these rights to individual members on the governance list without disclosing their exact identities to the token holders. Thus, if token holders want to exert soft pressure, they wouldn't even know who to target, nor who voted in support or against their interests.

Composability could also pair with richer contracts to allow for more creative interactions between token holders and delegates. For example, token holders could be allowed to unilaterally withdraw tokens from delegates, but would only receive the tokens after the minimum lock-up period ends. Composable contracts would be one way to achieve this.

Conclusion

Lock-up is not suitable for everyone; for those attracted by the initial efficiency advantages of token delegation programs, lock-up may seem unnecessary. However, lock-up is very useful for specific token holders interested in maintaining neutrality (e.g., founders, institutional holders, etc.).

Importantly, we want to clarify that some token holders want to give their delegates significant independence, while other token holders wish to establish a more closely monitored relationship. The status quo forces all these individuals into the same smart contract and lets them express their true intentions through patchwork public statements and legal documents. This contract allows each token holder to choose the framework that best suits them, including desired lock-up periods, mutual bypass functionalities, and emergency burn parameters. The entire process occurs on-chain, visible to everyone, with no need for oversight.