Formal Analysis Period for Larger Proposals

Ideas
1

[Copied over from Comadery]

Background

As Compound Governance evolves, it is becoming more obvious that certain proposals need a longer time for pre-vote analysis. For instance: The COMP issuance rebalancing proposal (CP011) effects not only Compound, but caused externalities that impact borrowing/supply demand such as Dai issuance and the Dai peg. These externalities affect both systems and deserve a more thorough analysis than proposals that are more straightforward. Compare CP011 to CP014 (née CP013), which aims to change the collateral factor for WBTC to be non-zero. This is a much more straightforward vote as the main economic risk factors deal with answering the following questions:

  1. Should WBTC be used as collateral in spite of the centralization/liquidity issues?
  2. Is 65% the right collateral factor? If not, why is it too low/high?

In order to accommodate the differences in analysis complexity (especially with regards to economics), we propose adding a formal analysis period to each vote.

On-Chain Formal Analysis Periods

A formal analysis period is defined as a non-voting period where a proposal is active (e.g. submitted on-chain). Right now, a proposal is defined such that voting starts at block height startBlock (defined as the predecessor block of the block height where propose is called) and ends at block height endBlock = startBlock + 17820 (roughly 3 days). With this format, all votes get the same time. We instead propose that another block height beginVotingBlock is added such that:

  1. The block height interval [startBlock, beginVotingBlock) represents a time where no votes are allowed to be cast but the proposal is on-chain (for provenance) and interested parties can inspect the proposal
  2. The block height interval [beginVotingBlock, endBlock] is exactly the same as the current voting interval
  3. We hold the invariant beginVotingBlock >= startBlock with startBlocks == beginVotingBlock equivalent to the current situation (e.g no formal analysis period)

Using the extra parameter beginVotingBlock allows for the proposer to signal and declare the following on-chain:

  1. The proposal requires at least analysis_time(proposal) = [startBlock, beginVotingBlock) blocks of analysis.
  2. If analysisTime(proposal) > analysisTime(proposal') , where proposal' is another proposal, then the proposer signals to all voters that proposal is worth more careful analysis (in terms of time) than proposal'
  3. By adding this as a parameter to GovernorAlpha.propose() each of these analysis periods is documented on-chain for provenance so that the community can later analyze which types of proposals need more/less analysis

The extra work of doing this on-chain will allow for the community to look back upon how different changes require different levels of analysis. This change requires a simple, two-line mutation to contracts/governance/GovernanceAlpha.sol :

function propose(address[] memory targets, uint[] memory values, string[] memory signatures, bytes[] memory calldatas, string memory description, uint memory analysisTime) public returns (uint) { … uint startBlock = add256(block.number, votingDelay()); uint beginVotingBlock = add256(startBlock, analysisTime); uint endBlock = add256(beginVotingBlock, votingPeriod()); … }

It is our belief that by documenting on-chain the relative amount of difficulty for each proposal, we can provide better analysis and guide informed decisions as Compound Governance manages an ever expanding set of digital assets.

6 Likes
2

I wanted to copy over @hayesgm’s comment too, which is important:

@Tarun, that makes sense, but why add a new variable when we could just adjust the votingDelay ? The intent of vote delay was to allow time to 1) analyze the proposal and 2) allow users to move tokens prior in anticipation of a vote (e.g. set-up delegation).

Also, changing the Timelock is a significantly more difficult task than changing the Governor. The Timelock has a fixed minimum of 2-days and swapping the Timelock requires changing the admin on each cToken.

1 Like
3

I’d like to push this proposal up the forum again for visibility. We are still having rather short voting periods for rather large adjustments, which makes it clear that voting is intended for persons that are checking the protocol daily, despite their actual stake in the protocol.

I would want to highlight the need to increase the amount of time it takes to properly evaluate a large change in the Compound protocol, and then the time it takes the individual to make an informed decision on said proposal.

2 days seems like an awfully short time considering the repercussions of the result.

Has there been a detailed analysis on voter participation in a 2-day timeframe vs let’s say a 5-day timeframe?

We are mature enough to consider such a move, especially since we’re the protocol that values safety over rash decision making. Only granting 2 days for big changes seems like a rushed effort, and I’d like to see this extended to multiple days, on top of the proposed formal analysis period.

Either way, there should be more option to discuss votes before they come on-chain, to simply avoid frustration, align expectation, and deliver the results that everyone wants to see manifest.

4 Likes
4

I’d like to second this opinion and thanks for bringing this up! I agree that the timeframe for voting is too short.

I’m a community contributor to the Index Coop and at the Coop we provide $INDEX holders the opportunity to vote on Compound proposals (through the tokens locked in the $DPI, which currently has ~$10.5M or 21’615 COMP in AuM). At the moment, the $DPI (and hence the Coop) is among the top 50 COMP holders.
We recently published our view on meta-governance, and stated our intention to take this responsibility seriously, and to act as informed and trusted token holder. However, we as community members can only inform INDEX tokens holders, we cannot vote for them. Hence, we want to do our best to keep INDEX holders updated, so that they can make an informed decision when voting.

Long story short, it would definitely be easier to achieve this, if we had more than 2-3 days. Currently we use Twitter and Discord to inform on new proposals. Ideally, we would have at least 5-7 days. This would give the community more time to prepare a summary (or potentially recommendations), and more time for Index holders to review the proposals.

2 Likes
5

Strongly agree!

The Governor Bravo (the second generation of governance contract) will support governance-set parameters like the votingDelay. This will be a great opportunity to set a longer voting delay, e.g. 1 day, before proposals begin the voting process.

4 Likes