Jump Crypto: How to Use Code to Ensure the Independence of Token Delegated Governance?
TechFlow Selected TechFlow Selected
Jump Crypto: How to Use Code to Ensure the Independence of Token Delegated Governance?
Holders can freely grant authorization, and agents can vote independently.
Navigating Web3 tides with focused insights
Authors: Nihar Shah, Joe Howarth
Translation: aididiaojp.eth, Foresight News
TL;DR
-
While token delegation programs enable robust governance, the independence of such delegations is limited because token holders can immediately revoke delegation rights.
-
For token holders requiring independence—such as institutional holders—we recommend embedding explicit lock-up periods into token delegation contracts.
-
We demonstrate this using Maker’s contract and add additional features allowing governance to bypass the lock-up period if both parties agree or if the token holder triggers an emergency override.
Introduction
Over the past two years, the concept of token delegation has grown increasingly popular. Token delegation allows token holders to assign their on-chain voting rights to others, and major protocols including Maker, Compound, and Uniswap have adopted delegation-based community governance. Delegation enhances governance participation and fosters thriving communities—including student groups, nonprofits, and community leaders.
Token delegation offers two distinct advantages. The most direct benefit is increased governance efficiency. Without delegation, some community members with minimal stakes or limited time would still need to review dozens of proposals and navigate complex governance mechanisms to vote. Through delegation, specialized representatives can make more informed, consistent, and impactful decisions. In many cases, representative democracy holds advantages over direct democracy—and crypto markets are no exception.
A second advantage of token delegation has emerged over the past year: neutrality. For instance, certain token holders may hold large positions and also own tokens in competing protocols. These holders might wish to support a decentralized and impartial community, and delegating voting rights serves as a way to demonstrate neutrality.
However, this second advantage cannot be achieved through delegation alone—it requires special conditions ensuring representatives act independently from token holders. For example, a16z's Jeff Amico articulated principles for token delegation in his article, emphasizing the importance of “empowering each delegate to vote independently of the token holder in any manner they see fit.” Yet most existing token delegation systems do not enforce such independence, and in some cases, it can be deliberately undermined just before critical governance votes.
This article proposes a simple, code-based solution: adding lock-up periods directly into the protocol so that token holders cannot revoke a delegate’s governance rights during the locked period. We provide a reference implementation of this concept, along with optional bidirectional non-emergency and unilateral emergency override features compatible with Maker’s protocol.
Paradise Lost: Revoking Delegation
Although widely seen as promising, token delegation is not without criticism. Both theoretically and practically, delegation programs often overlook norms around authorization, undermining efforts to build sound governance.
For example, Chris Blec of DeFi Watch has consistently advocated for clearer choice and interaction standards in a16z’s proposed delegation program. Blec points out that if governance proposals are approved solely by one or two holder-appointed delegates, questions arise about the relationship between delegates and token holders.
These risks are real. Beyond Maker’s Poll 819—better known as the LOVE vote—this proposal centered on selecting loan oversight entities and sparked broader community debate on decentralization versus efficiency. The vote was highly contentious and exceptionally active (it set Maker’s record for voter participation, which still stands at the time of writing). Luca Prosperi documented the broader voting process in detail, particularly focusing on delegation-related specifics.
This illustrates how key governance proposals can circumvent delegation mechanisms. For example, Maker founder Rune Christensen changed his delegation during the voting period, thereby influencing the outcome. Although Christensen publicly opposed the proposal, he had delegated nearly all of his MKR tokens. However, during the two-week voting window, he revoked the delegation from representatives who voted “yes” or abstained, reassigning those tokens to other undelegated representatives. This reallocation appeared to be a tactical move to obscure fundamental disagreements between Christensen and the “yes”-voting delegates. Three days after the vote concluded, Christensen reassigned delegation back to the same “yes”-voting representatives from the prior election. This pattern is illustrated below:
Legal Solutions
Token delegation programs need to become more robust. One approach involves using legal contracts to guarantee delegation independence and enforceability—for example, a16z’s delegation program includes commitments specifying minimum durations for which representatives retain governance rights. This reduces the risk of token holders reclaiming control when conflicts of interest arise. More generally, it limits the pressure token holders can exert on their delegates.
This principle is enforced via legal agreements stored in a public GitHub repository. A key clause appears in Section 6: “To prevent potential failure of the delegate to fulfill their governance responsibilities under the protocol, the initial term of this agreement shall be [N] months from the effective date, and the token holder may only terminate this agreement upon expiration of the term.”
However, legal mechanisms are suboptimal. While we do not question a16z’s integrity, others following their lead may lack similar principles. Legal contracts are costly to enforce and embed asymmetric power dynamics, often involving opaque negotiations. In the hands of indifferent token holders, legal agreements offer little meaningful oversight.
Therefore, due to heavy reliance on assumptions about transparency and enforceability, legal contracts may be the wrong mechanism for broadly scaling and strengthening token delegation programs.
Proposal: Code Over Law
This article proposes a simpler solution: smart contracts instead of legal contracts. Specifically, embedding lock-up periods directly into smart contracts to protect delegate independence. This approach is highly transparent upfront, easily enforceable afterward, and above all, technically straightforward to implement.
We demonstrate using Maker’s contract. Most core delegation logic resides within the VoteDelegate.sol contract, particularly the lock and free functions, which already largely meet our needs. Token holders use the lock function to bind tokens and assign governance rights, and the free function to reclaim those tokens and associated rights.
Only minor modifications are needed. First, define a variable called _lockupPeriod when calling the contract constructor. Second, token holders trigger an unlock countdown by calling the initialUnlock function. Third, modify the free function slightly to ensure compliance with the lock-up period.
By embedding lock-up periods, token delegation becomes more publicly verifiable and trustable, with delegate independence enforced by code rather than legal terms.
Emergency Override Features
Of course, lock-up periods may not always be desirable, and the smart contract can be adapted accordingly.
First, trustees and token holders may mutually agree to end the delegation relationship. In such cases, a bypass function can be provided—implemented via a simple function called delegatorBypassLockup, enabling the delegate to relinquish governance rights without delay. (Note: the parameter isDelegatorBypassEnabled can be enabled at contract deployment.)
Second, there may be emergencies where token holders need to unilaterally bypass the lock-up period—for example, if a delegate acts in a highly irresponsible or adversarial manner—though such cases should be rare.
A viable solution is to allow token holders to bypass the lock-up by irreversibly burning tokens—a straightforward mechanism to implement. During contract initialization, the token owner sets an EmergencyUnlockBurnPercent value (potentially up to 100%). Then, modify the free function to check whether the token holder selects the emergency route. If so, it returns only the unburned portion of tokens and burns the remainder. Part of this logic is shown here:
Complete Token Vault
The full set of function requests incorporating all features and modifications discussed in this article can be found in this public GitHub repository, including all necessary changes for integration with Maker’s architecture. We welcome feedback and believe this contract is ready for production deployment.
Future Vision: Composability
Token delegation programs can become richer. We believe composability of delegation contracts will unlock the next wave of innovation—for example, what if delegates could further delegate their voting rights to other delegates?
Such arrangements could enhance delegate independence. For instance, a token holder might delegate tokens to a student group, which in turn delegates voting rights to individual members on a governance list without revealing their identities to the original holder. Thus, even if the token holder attempts to exert soft pressure, they wouldn’t know whom to target or who voted for or against their interests.
Composability can also pair with richer contracts to enable more creative interactions between token holders and delegates. For example, token holders could be allowed to unilaterally withdraw tokens from a delegate but only receive them after the minimum lock-up period ends. Composable contracts could enable such functionality.
Conclusion
Lock-ups aren’t for everyone. Those drawn to delegation primarily for its efficiency benefits may find lock-ups unnecessary. However, lock-ups are highly valuable for specific token holders interested in maintaining neutrality—such as founders or institutional holders.
Crucially, we want clarity: some token holders want to grant their delegates significant independence, while others prefer tighter oversight. The current status quo forces all into the same smart contract, relying on ad-hoc public statements and legal documents to express intent. Our proposed contract enables each token holder to choose their preferred framework—including desired lock-up periods, mutual bypass options, and emergency burn parameters. The entire process occurs on-chain, visible to all, with no need for external monitoring.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
