owned this note
owned this note
Published
Linked with GitHub
The primary goal of this paper is to promote further research, development, and adoption of on-chain governance by presenting ideas for how today’s systems can potentially improve. It was written with the intent to encourage thought-provoking discussions that might challenge the status quo and bring fresh, innovative perspectives in governance design.
# Introduction
Before delving into the intricacies of protocol *governance*, it's crucial to establish what a protocol actually represents. In the scope of this paper, a protocol is defined as a set of rules, implemented and enforced by smart contracts on the blockchain, that offer utility to digital assets. In simpler terms, protocols are the code that create uses for digital assets on the blockchain.
Blockchain protocols are exceptional due to the characteristics of their underlying technology: credibly neutral, deterministic, and eternally persistent. Every user has unequivocal access to the same underlying utility of a blockchain protocol. The system harbors no implicit biases or special exceptions, unless explicitly programmed in that manner.
This is the beauty of crypto protocols: [they function as global public utilities, indiscriminately and permanently delivering benefits to individuals all around the world.](https://jacob.energy/hyperstructures.html)
Anyone acquainted with the current crypto ecosystem would know that most 'protocols' today fall short of this ideal. Often times, crypto protocols resemble unregistered businesses, operating manually and with various points of authorized access. For these protocols, without a trusted team to facilitate protocol operations, they are likely to fail.
It's important to distinguish between businesses and protocols. Their primary difference lies in their incentives: businesses exist primarily to generate profit, whereas protocols simply exist. Because of this, different considerations need to be made when designing the rules of their decision making process.
---
# Protocol Mutability
One of the first choices a developer makes for their protocol is the mutability; more specifically, whether the code can be modified and, if so, how. Generally, there are three options available: immutable, authorized, or on-chain governed. Each choice comes with its own set of trade-offs and considerations.
The first option, immutable protocols, are protocols that cannot be changed. These protocols are the most reliable because they are guaranteed to behave the same way. However, this is also their primary drawback: they cannot be fixed or upraded if something is wrong. This locks users out of all potential future utility in the system and forces users to migrate to entirely new smart contracts when changes are eventually made to the protocol.
The second option, authorized protocols, are protocols where changes in the system are made by trusted individuals with privileged access. This allows protocols to respond quickly to unforeseen problems and upgrade seamlessly, creating a convenient experience for users. However, this approach comes at the cost of reliability, negating one of the key advantages to existing on a blockchain.
Changes to authorized protocols are sometimes made in coordination with an off-chain vote as a form of “pseudo democracy”. However, off-chain voting cannot be recognized as legitimate protocol governance, because there’s no way to enforce accountability for their outcomes—at least from the perspective of a blockchain. It’s possible (and sadly common) for priveleged individuals to exploit their protocols, making unilteral changes to system at the expense of the community, for their personal benefit.
This brings us to the final option: on-chain governed protocols. With on-chain governance, a protocol’s code possesses the ability to modify itself in a systematic process. Voters can preview upcoming changes and provide their consent prior to it being implemented. Most importantly, governance outcomes are enforced by pre-established rules written in code. This model strikes a compelling balance between immutable and authorized protocols by allowing upgrades to happen, but in a deterministic way.
It is important to highlight that on-chain governance is not foolproof. The process of voting on the blockchain demands a considerable degree of collective coordination, time, and effort, making it slow and laborious. Additionally, being on-chain does not automatically guarantee safety for protocol users; the governance process itself remains vulnerable to exploitation, and while technically transparent, proposed changes can be hard to understand for voters lacking specialized knowledge.
Despite these drawbacks, however, on-chain governance remains the only viable option for protocols striving for credible neutrality and longevity. By facilitating code changes in a transparent and predetermined manner, a protocol's ability to succeed and grow is decoupled from the existence of specific individuals and their contributions.
---
# Governance **Mechanisms**
When designing governance mechanisms, it's crucial to consider the system’s primary aims and objectives. Good governance processes decisions quickly with minimal effort, and a high likelihood of acceptance. Conversly, bad or ineffective governance is slow, requires a lot of attention, and has unclear resolution.
The governance process can be broken into four main parts: proposal submission, voter representation, decision consensus, and execution.
- **Proposal submission** defines the circumstances and requirements for new proposals to enter the system.
- **Voter representation** specifies how voting power is calculated within the system.
- **Decision consensus** is the algorithm used to determine how proposals are ratified.
- **Execution** describes the terms and conditions around implementation of the proposed changes.
Each of these elements carries their own design decisions and incentives to consider in the development of an on-chain governance system.
## **1. Proposal Submission**
Proposal submission emcompasses who can put forth proposals, the prerequisites for doing so, and how proposed changes are expressed. Mechanisms tied to proposal submission serve as a filter for governance decisions, deterring malicious or unnecessary proposals from entering a vote while encouraging constructive and beneficial proposals to be submitted.
### **Proposal Collateral**
One mechanism that can be utilized is a *proposal collateral*. This feature mandates potential proposers to deposit a certain amount of liquid assets into the system to initiate a proposal. If the proposal is unsuccessful, the collateral is locked for a predetermined penalty period. This setup encourages proposers to be confident in their proposals' potential success before submission.
It’s crucial that collateral is locked but not slashed for failed proposals. Inflicting financial penalties for unsuccessful proposals can lead to undesired outcomes by discouraging participation and stifling innovation. In contrast, locking collateral for a period of time imposes a cost without risk, helping distinguish between those that are genuinely invested and those that are transient participants unwilling to make long term commitments in governance.
The amount of collateral required by a system should be proportional to its voting capacity; the cost to vote on a proposal escalates with the amount of participating votes. This is best calculated as some multiple of a fixed percentage of the vote supply, with some minimum amount to ensure a baseline cost when participation is low. The exact percentage and minimum for proposal collateral can vary based on the unique system.
### Asset Types
The asset used as proposal collateral the collateral asset should be a token with good liquidity, as locking its liquidity is what creates the desired incentive for the mechanic. One potential idea to explore is to collateralizing liquidity tokens (LP) themselves, such as pairs with the protocol’s native token. This way, token liquidity scales with the proposal volume of the system.
In fact, the collateral asset does not have to be related to the underlying protocol at all—even ETH could serve as effective proposal collateral. The specific asset used for proposal collateral is insignificant, just that the collateral asset is never the vote itself. Otherwise, the volume of proposals in the system can impact the quorum of future votes, potentially affecting their outcomes in unexpected ways. It’s best for the vote capacity and volume of submitted proposals to remain independent, since no advantages are gained from conflating the two.
### **Collateral Utilization**
While proposal collateral is locked in the governance system, it can be put to productive use to generate revenue as protocol-owned assets. This approach challenges the traditional view of governance as a "necessary cost" for protocols and reframes it as a potential "profit generator".
An effective example might be a governance system opting to use ETH as proposal collateral, which can be staked for validator rewards during its custody period. Similar approaches may be adopted for liquidity pool (LP) tokens as collateral to be deposited into yield aggregators or farms. Each protocol must decide the appropriate level of complexity and exposure to risk for its own collateral utilization strategy.
The possibility for strategies not only opens up a new range of mechanics around protocol interactions but also fosters greater potential alignment across protocol users and operators. For instance, a decentralized exchange (DEX) can use its base liquidity pair as governance collateral, or a stablecoin protocol could use its native synthetic asset. Such strategies align protocol growth with governance participation, boosting the overall utility of their systems. This could help protocols bootstrap adoption through endogenous usage from their governance system.
### **Proposal Rewards**
The requirement for collateral imposes a cost to submitting proposals, which should be counterbalanced with governance rewards. Absent these rewards, there would be no clear incentive for anyone to participate in the governance process, thereby reducing the number of good ideas surfaced and limiting opportunities for the protocol to be further improved.
Many governance systems today suffer from low engagement for this exact reason. Typically, new proposals are only submitted by those who have pre-existing incentives with the protocol, such as team members, significant token holders, or external protocols seeking to access or use internal protocol resources. These incentives, however, excludes a majority of users. Once they dissipate, the project is at risk of stagnation; there's no inherent mechanism to keep it going. To address this issue, governance systems should issue a reward when a submitted proposal is successfully executed, similar to a block reward in blockchains. This approach provides an inherent incentive for anyone to submit a proposal at any time.
### **Proposal Content**
On-chain governance proposals are never plain-text suggestions; they must always be executable pieces of code. This is the only way to enforce direct accountability for governance outcomes. As a result, proposal implemention is completed beforehand, holding submitters responsible for carrying out any related work in advance. Proposals as software paves the way for changes to be predictably and transparently introduced; their expectations are predefined, ensuring that all intentions are clearaly articulated in the code prior to execution.
Today, the vast majority of on-chain governance proposals are used for adjusting various system parameters, but this doesn’t have to be the only use case. For example, protocols built using the [Default Framework](https://www.notion.so/Default-A-Design-Pattern-for-Better-Protocol-Development-7f8ace6d263c4303b108dc5f8c3055b1?pvs=21) could use governance proposals to upgrade the underlying architecture and logic of the code itself, changing the core utility proposition and mechanics of the system. The possibilities around what software-based proposals can achieve are limitless, and should definitely be further explored.
---
## **2. Voter Representation**
Voter representation determines the types of proposals submitted to the system and the incentives involved when deciding their outcomes. Because voters are likely to change the system for their own benefit, design decisions around voter representation most directly shape the future of the protocol itself.
### **Vote Denomination**
The most common practice today is for the holders of a protocol’s “governance token” as the primary denomination for votes. However, this isn’t necessarily practical, effective, or beneficial to the protocol; possession of a token doesn’t necessarily correlate to any usage of the underlying system. Thus, the incentives of token holders for a protocol can differ significantly from those of its users, as holders tend to prioritize value extraction from a system, while users are more likely to prioritize adding utility.
Instead, votes should be denominated in assets that signify system usage, not an asset that 'manages' it. It makes the most sense for decisions concerning a protocol to be made by those who actively rely on its utility, after all. As an example, decentralized exchanges could use liquidity tokens to represent votes; lending protocols could use deposit receipts; and stablecoins could use the native stable asset to denominate decision making in their protocols.
### Defined Voting Quorums
Assets used to denominate votes should be wrapped and denominated separately in governance. This makes minting votes an opt-in process rather than a passive benefit of a token. When users explicitly communicate their intent to participate, the voting quorum is more clearly defined, allowing more accurate analysis and interpretation of outcomes. Relying on simple token snapshots is not an effective way to count votes, since tokens inside liquidity pools or held at exchanges are included in the quorum, obscuring the outcome of a vote.
In addition, votes themselves should be non-transferrable and illiquid, reflecting their purpose as decision-making rights rather than financial assets. As a result, the assets backing the votes should be non-redeemable until the corresponding votes are returned. This is especially the case if votes are used during a proposal, as they need to be locked for at least the duration of the proposal to ensure voters are accountable for their governance decisions.
### **Vault Strategies**
Minting votes can be handled via a vault mechanism; where assets are deposited and votes are minted in exchange. This model presents unique opportunities for additional innovations in governance systems, and utiliing voting vault mechanisms can help create additional alignment within a protocol.
One obvious strategy is to introduce protocol fees into the vault; a portion of the fees collected from protocol transactions could be distributed to active voters. This could align incentives for both governance participation and protocol usage, potentially fostering more interest and loyalty within a protocol's community.
However, protocol fees are just the tip of the iceberg. Depending on the specific context and goals of the protocol, the utility of the voting vault could be a core function of the system itself. This mechanic, in conjunction with collateral utilization, can create powerful new paradigms in the role governance plays in a protocol.
It's important to note, however, that while these strategies could potentially drive engagement, they must be implemented thoughtfully. Overly aggressive incentives could lead to unforeseen consequences, such as encouraging excessive risk-taking or fostering a purely profit-driven community. The design of vault strategies should always align with the broader goals and values of the protocol.
### **Delegation**
While delegation is a common feature in many existing governance systems, this paper intentionally omits it as a native feature of on-chain governance. This is not to suggest that delegation is inherently undesirable, but rather to propose that it functions more effectively as an externalized effect.
As a concept, delegation is about complex aggregations of ownership that participate in governance as singular entities, and the various ways this can be achieved. When delegation is exogenous to the system, it can take on arbitrary and sophisticated forms, allowing it to grow and evolve with the governance process.
Today, delegation is mostly just individuals simply forwarding their votes to others, but effective delegation can be so much more: rather than simply electing representatives, delegation can take the form of "political parties" or subDAOs as lobbying entities. In this format, delegation takes on a more robust and sophisticated structure; smart contracts can be deployed to consolidate these different pockets of ownership, which then engage with the governance system collectively. This approach enables a more nuanced form of delegation and, ideally, results in a more diverse representation of interests within the governance process.
Unintuitively, not pre-defining delegation in a governance system helps realize its full potential more easily. In addition, it drastically reduces the complexity of the internal representation of votes, simplifying the mechanics of the system.
---
## **3. Consensus**
A governance consensus mechanism consists of two components: a quorum and a finality threshold. The quorum which is the minimum number of votes required for a vote to be considered “valid”, while the finality threshold refers the relative count of votes necessary to consider a decision ‘accepted’ by a group.
Many governance systems today to employ a static quorum and a simple majority determination for their finality threshold, but this approach can cause problems. One concern is the system’s vulnerability to "**[tyranny of the majority](https://en.wikipedia.org/wiki/Tyranny_of_the_majority)**", where a voting majority can enforce decisions that benefit them at the expense of minority participants.
For protocols to remain credibly netural, they need to consider everyone’s interests. Unfortunately, there is no way to design a perfect system that fulfills everyone’s preferences, but there are mechanisms that can measure opinions in a more nuanced way.
### **Delta Thresholds**
One possibility is to use delta threshold to count votes, which is a method of determining finality based on the difference in votes for and against a proposal. Unlike the majority rule method, delta thresholds account for the contentiousness of a proposal, resulting in dynamic quorums and participation requirements that adjusts to the contentiousness of a given proposal.
Calculating votes with a delta threshold is simple: subtract the total NO votes from the total YES votes; this difference needs to exceed a set percentage of the total voting capacity. This percentage is the 'delta threshold'; the minimum difference in votes required for a consensus to be achieved.
Using this method, proposals facing increased opposition require larger quorums to pass, while undisputed proposals require fewer voters involved in the decision making process. This allows for generally swift decision-making, while still slowing down when decisions become highly controversial.
Delta thresholds prevent a tyranny of the majority situation by enabling a minority veto; a minimum number of votes needed to unilterally stop any proposal. The minority veto percentage is naturally a function of the delta threshold, calculated as follows:
`minority veto percentage = 100 - (( 100 + delta threshold ) / 2)`
This percentage can also be seen as the 'centralization threshold' - if an entity possesses enough votes to overcome the minority veto, it would effectively control the protocol. This would render the protocol 'centralized', similar to how a 51% attack works in Bitcoin. Each protocol can configure this for themselves, as higher thresholds leads to a lower minority veto requirement, enforcing higher standards for decentralization.
### Proposal **Endorsements**
Following a proposal submission, an endorsement period takes place prior to the official vote. Endorsements act as a means of proposal priortization in governance, expressed as pre-committed YES votes to broadcast significant and interest in certain decisions.
The number of endorsements should always match the delta threshold for two key reasons: firstly, it allows proposals to pass by default, meaning a proposal passes by default if no action is taken, reducing overall decision friction. Secondly, counting opposing NO votes for a proposal is unnecessary if there aren't enough prerequisite YES votes to begin with. In this way, endorsements act as a secondary filter in governance, allowing governance participants to only focus their attention on proposals with a high likelihood of passing.
Once a proposal receives the necessary endorsements, an official vote begins. The primary purpose for the vote is to measure opposition for the proposal; participants can vote NO and previous endorsements can change their votes to prevent the proposal from going through. This way, enough interest and intent must be broadcast for a decision to be made before consensus needs to be measured.
When implementing endorsements and voting resolution, It’s important to specify time constraints. Proposals should be disabled if they are not ratified in time to prevent dormant proposals from being suddenly activated and reduce attention overhead for governance participants when evaluating decisions.
---
## **4. Execution**
Once a vote achieves consensus, the changes in a proposal can be implemented. However, there are still design decisions to optimize this process: how long should a protocol wait before executing the software in a proposal? And what is the deadline for the changes to take place? Good governance clearly defines expectations, so these two mechanisms are important to consider in order to create an effective governance system.
### **Execution Timelock**
Once a vote has passed, a time delay should be instituted before the execution of the proposed code. This delay provides protocol users an opportunity to respond to impending changes before their actual implementation, allowing users to “rage quit” the protocol if possible. This ensures that users aren't taken by surprise by governance decisions, affording them a safe exit from the protocol if any incoming changes impact them adversely.
### **Execution Deadline**
On a similar note, once a proposal has passed, users should know the changes will come by a certain time. Implementing a deadline encourages prompt action after decisions are finalized, helping the governance process stay quick and efficient. Deadlines also preventing the sudden activation of long-dormant proposals, reducing potential attack vectors.
Since code is on-chain software, its execution can be expensive. As a result, the responsibility to pay the gas fees should rest with the initial proposer. Since they should receive a reward for the successful execution of their proposal, they should be incentivized to pay the associated costs. If for any reason a proposal is not executed, even after it’s successfully approved, it can be resubmitted by other governance participants, allowing for the free expression of ideas in the system.
---
# Final Thoughts
When utilized correctly, on-chain governance systems can dramatically reshape how decentralized protocols operate, progress, and scale. Our hope is that by presenting some concepts and ideas around how on-chain can be improved, we can elevate the discussions and expectations people in crypto have around governance. On-chain governance holds powerful potential, and by holding protocols to a higher standard, we can see the emergence of safer, fairer, and more scalable systems than the ones we have today.