Formal Analysis Period for Larger Proposals

[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.

4 Likes

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