P0: We Need Stake Based Decentralized Scrum
Agile project management has demonstrated the value of limiting organizational throughput; restricting the number of tasks at any one time leads to greater efficiency and better prioritization. However, traditional agile development relies on a “scrum master” with ultimate control over the pipeline, making it problematic to implement in decentralized governance systems.
Compound limits the pace of governance by requiring 100k of delegated COMP (1% of total supply) to submit a proposal, along with 400k COMP in total participation to reach quorum. While this surely helps prevent spam proposals and cuts down on mental overhead, it also limits the ability of small holders to influence governance (100k COMP required to submit a proposal is worth over $10M at time of writing).
Maker takes a different approach with continuous approval voting. There is no minimum limit required to propose an executive vote, but in order for the vote to pass it must accumulate more MKR support than the current governing proposal (typically 5–10% of outstanding MKR). Additionally, the official voting user interface is controlled by an elected Maker governance facilitator, who can determine which proposals are displayed based on community convention and procedures.
One advantage of the Maker system is it generally operates on predictable weekly and monthly cycles, which ensures MKR voters know when it’s time to participate without consistent engagement. The governance facilitator and domain teams are empowered to submit out of sequence proposals, which allows Maker to take emergency action when necessary. This reliance on individual contributors rather than token holders to control the voting agenda could be seen as a weakness of the Maker system, as it introduces potential centralized points of failure in the proposal process.
An ideal governance system should ensure predictable, manageable workloads for voters, while maintaining a decentralized proposal process. I believe that this can be accomplished by incorporating certain features of both Compound and Makers’ governance into an agile development workflow.
Agile management is organized around the concept of a sprint, an organizational device that splits longer term projects into short increments (typically 1–2 weeks). Teams will plan their work by breaking the project down into individual tasks that can be completed within a sprint, and then prioritizing which tasks are most important. This allows teams to begin shipping potentially usable work product as soon as possible, while ensuring that lower value tasks are only addressed if there is a surplus of time or resources.
Decentralized governance systems such as Compound could adapt this sprint methodology by establishing governance cycles of fixed length, and then limiting the number of individual proposals that can be considered during each period. This will increase predictability for COMP holders while limiting the time and effort required to participate.
In Compound’s case, this sprint framework could be implemented using the pre-existing delegation and proposal thresholds, with no human scrum master required. To describe how this would work, I’ll rely on another agile stalwart: prioritization levels. Each task in an agile project can be rated from P0 to P4, based on its relative urgency. P0 refers to critical issues requiring immediate attention that supersedes prior plans, while P4 corresponds to superficial or informational issues that can be delayed indefinitely.
Compound’s current governance flow requires 100k COMP to submit a proposal, which is then immediately presented to participants for a 2 day voting period. Because the vote is submitted to COMP holders without regard to a particular weekly or monthly governance cycle, this could be considered to be a P0 proposal process. Considering the short voting period and lack of advanced notice to participants, a substantial proposal submission threshold is needed to prevent abuse.
Compound may be able to loosen the minimum COMP submission threshold by instituting a predictable monthly governance cycle with COMP weighted priority levels. Anyone holding over 100k COMP would still be able to submit a proposal as P0 for immediate voting, which ensures that mission critical changes can be made in a timely manner. Any proposals submitted with less than 100k COMP in support would be added to the governance backlog, with the subsequent process determined by the proposal’s priority level.
The COMP stake required for each priority level could be set flexibly by governance. So while submitting a proposal as P0 requires 100k COMP and leads to an immediate vote, submitting a proposal to the governance backlog as P1 could require perhaps only 30k COMP, with 10k COMP for P2, 3k COMP for P3, and 1k COMP for P4. At the beginning of each governance sprint, any proposals that had been added to the backlog at least
d days in the past will be automatically scheduled for a vote based on their priority.
The system would be designed to cap overall throughput of proposals, ensuring that governance bandwidth is expended on the most valuable changes. While P1 proposals could be guaranteed to go up for a vote during the next available governance sprint, P2 through P4 would be scheduled for a vote only if the total number of proposals scheduled during the sprint does not exceed a governance determined parameter
n. In cases where the total number of proposals in the backlog exceeds
n, proposals will be ranked for inclusion in the sprint first by P level (with all P1s included even if they exceed
n), and then by the time they were submitted.
To prevent spamming, each address can submit only a single proposal to the backlog at a time. Similar to the current framework, if a proposer loses votes after submitting their proposal and it falls below the relevant threshold, the proposal can be canceled. This should help prevent a proliferation of lesser backed proposals, as time with COMP staked on a low priority proposal introduces a sort of governance opportunity cost where one’s vote could be having more impact.
Given that proposals would be processed in batches, a method is needed to adjudicate between conflicting proposals. Advantage will be given first to higher priority proposals, and then to proposals that were submitted first (similar to sprint inclusion criteria). In order to enforce this preference ordering without manual intervention, each proposal will be given a nonce, beginning with the last proposal accepted into the sprint and ending with the first proposal accepted (e.g. the first submitted P1 proposal). While the proposal contracts would all become “available for execution” on a specified release day after voting had concluded, the governance system would require them to be executed based on their nonce order. This would ensure that higher ranked / earlier submitted proposals will be executed last, superseding any conflicting votes.
What are the potential impacts of this change?
By drastically lowering the barriers to entry for direct participation in Compound governance, we may see more engagement from smaller scale, less well resourced leaders. Ultimately, COMP may gain additional utility as a work token that developers and builders can stake to propose protocol enhancements, while attaching invoices in a form of reverse contract tendering.
On the other hand, if not implemented carefully it could increase the viability of vote renting. As long as the amount of COMP required for the minimum P4 priority remains considerable and the maximum sprint throughput
n is low enough to block lesser backed proposals, the risks should be manageable.
With the help of a willing superdelegate sponsor, it might even be possible to role play the impact of this sort of change before making any changes live in production. Delegates with sufficient voting power could post proposals off-chain and attest to their submission via an on chain signature. If proposals are submitted in time for the mock sprint (at least
t days before the start time), and proposer voting power hasn’t at any time fallen below the minimum required (which would lead to cancellation), the sponsor can submit the proposal(s) for an on chain vote according to the sprint prioritization rules, using their regular 100k COMP stake.