DAO governance MVP plan outline
Closed this issue · 12 comments
Code4rena DAO governance MVP high level:
- Set up and deploy contracts for vanilla Compound governance setup
- Test suite for contracts
- #7
- #5
- #6
- #4
- #8
- #2
- For proposals: setup a website or connect to an available website
- #3
- Be able to take a genesis block (with vesting)
- Conduct initial token sale to token purchasers
Let's use this thread to hash out details and start creating issues to stub out the work needed. This is my understanding of action items from the call:
- @zscole can you please link to and/or upload the reference contracts and deploy scripts you mentioned?
- @0xleastwood and @HickupHH3 to handle setting up contracts
- @MrToph to handle creating tests
- @gpersoon to contribute as needed to the above
Please review / comment / correct these lists.
C4 is light on contests this week, so maybe we can make a good run at this and get it done by next Monday.
What do you all think?
the contract is just basic a erc-20 and the deployment scripts use hardhat.
Do we go with CompoundGovernorBravo? The only difference with this over Alpha is that an additional option of abstain.
Some technical implementation details to be discussed:
Refer to the compound governance docs for more information about the governance process. Nevertheless, I've added the descriptions for the terms / variables to be discussed for convenience.
1. We'll have to fork the Comp token instead of using a basic ERC20 because the getPriorVotes() function is required for governance.
2. Are there any changes to be made for the default values of the timelock and governor contracts?
Timelock
Grace Period
GRACE_PERIOD = 14 days. This is the duration allowed for proposal execution after queueing. After which, another proposal will have to be created
Delays
MINIMUM_DELAY = 2 days, MAXIMUM_DELAY = 30 days. The lower and upper bounds which the timelock delay can be modified to. The timelock delay refers to the least amount of notice possible for a governance action, or the time duration between a proposal passing and its execution.
GovernorBravo
Proposal Thresholds
MIN_PROPOSAL_THRESHOLD = 50000e18 (50k tokens), MAX_PROPOSAL_THRESHOLD = 100000e18 (100k tokens). The lower and upper bounds which the proposal threshold can be modified to. The proposal threshold is the minimum amount of tokens required for proposal creation. Note that a proposal can be cancelled if the proposer's voting power falls below this threshold anytime before proposal execution.
Voting Period
MIN_VOTING_PERIOD = 5760 blocks (~24 hours), MAX_VOTING_PERIOD = 80640 (~2 weeks). The lower and upper bounds which the voting period can be modified to.
Voting Delay
MIN_VOTING_DELAY = 1, MAX_VOTING_DELAY = 40320 (~1 week). The lower and upper bounds which the voting delay can be modified to. The voting delay refers to the duration (in blocks) between proposal creation and start block of the vote casting.
Quorum Votes
quorumVotes = 400000e18 (400k tokens). This is the minimum no. of votes in support of a proposal required in order for a quorum to be reached and for a vote to succeed.
proposalMaxOperations
Refers to the maximum number of actions that can be included in a proposal. Set to 10.
3. In addition to the global values, what would be the initial values for the following variables?
- Timelock delay
- Voting period
- Voting delay
- Proposal threshold
4. Token Details
- Token Name
- Token Symbol
- Token Supply
- Mintable / Burnable?
- #3
5. Solidity Version
Compound uses 0.5.16, do we want to bump it to the latest version? Provides nice features like custom errors and native integer flow checks, downside being modifying the contracts
Openzeppelin has made a solidity 0.8.x version of the contracts:
https://docs.openzeppelin.com/contracts/4.x/api/governance
https://docs.openzeppelin.com/contracts/4.x/governance#erc20votes_erc20votescomp
Ohh sweet, will be better to use those contracts then
Bringing @HickupHH3's comment in chat here:
@gpersoon pointed out that OZ has a governance module. They have a wizard that makes it really easy to configure the token and governor contracts:
https://wizard.openzeppelin.com/#governorThe guide can be found here:
https://docs.openzeppelin.com/contracts/4.x/governanceWhile Boardroom doesn't seem to have support for OZ's Governor contract (I reckon they will eventually support it), there is a
GovernorCompatibilityBravothat can make the Governor contract compatible.The guide mentions that their framework is supported by Tally, which is an alternative to Boardroom: https://www.withtally.com/
I asked:
Is the list of defaults and options in the wizard basically the same as the outline of questions and details you made in GitHub?
@HickupHH3 replied:
Yeah they're the same. The min / max global options I mentioned on GitHub can be ignored.
Only have to decide on the initial values
ItsmeSTYJ added this note:
https://twitter.com/TimBeiko/status/1456644168986419200
OZ's governance uses block intervals for voting periods so this is something that we might want to keep in mind.
So just to update where I think we're at:
- Use OZ wizard to set up contracts
- Use Polygon for primary Code4rena governance chain. (See discussion in #2)
Use Tally instead of Boardroom (since it supports Polygon)(EDIT: it doesn't)
Once the DAO is deployed:
- Mint full token set to DAO treasury
- Mint initial airdrop token distribution
- Take governance action for vesting tokens
- Take governance action to perform token sale (with vesting)
If I understand correctly, this is what remains in terms of decision points and information needed at this point, along with my best working answer for each:
- Proposal threshold (.1% of supply seems reasonable)
- Quorum threshold (5% of supply seems reasonable)
- Timelock delay, voting period, voting delay (default seems fine on these)
- Token Name (Code4rena)
- Token Symbol ($C4)
- Token Supply (1 billion)
- Mintable / Burnable? (Yes)
- #5
- #6
- #3
Unknowns:
- Do we still need testing or do the OZ contracts come with a full test suite?
- What else am I missing?
Let's just use "C4" for the token name. It won't translate on Twitter because their auto-linking breaks when you have numbers in the cashtag, but I don't really think that matters in the end.
Tally not supporting Polygon puts us back a few steps.
I do think there's enough expressed concern that gas will staying high for long enough into the foreseeable future that we want to put our treasury on Polygon given we have a lot of small awards and those drive people to get involved who can grow into major warden contributors long-term.
@zscole suggested Aragon, @gpersoon expressed some hesitation (though acknowledged it was not through direct experience) and raised Daohaus as another option on Polygon.
A couple people have asked whether we want to just do snapshot and multisig (which we can do on Polygon). My gut sense is that's not ideal, though it does but it might be fine as a first step if we include an election of multisig holders, especially because one of the challenges we need to solve downstream is how we handle the messiness of multiple chains.
So—we need to get some consensus on where we go on this decision tree:
Then there are other decisions that will need to flow downstream from whichever choice we make there, many of which have been identified already. The biggest ones are:
- What order of operations do we need? (Do we have to do things all at once including token vesting or can we take multiple steps?) I assume some of this will be on constraints of the platform we choose.
- How do we handle assets on other chains? (I assume we probably have to just delegate an EOA)
- How do we handle the airdrop distribution itself? Set up an interface for claims or distribute directly?
- To speed things up, I suggest having a multisig / single EOA to be the admin before handing over control to a timelock contract.
a) Launch Token contract
b) Mint tokens to merkle distributor / transfer tokens directly to users. I prefer using a merkle distributor, because we can create and plug in a vesting contract (this answers qn 3).
c) Deploy governance framework, which the multisig / EOA transfers token admin to.
d) Governance to mint and send tokens to a token sale contract.
While the minting of tokens for the token sale can be performed prior to transferring admin control to governance, it should be executed before the start of the token sale, because it is only at this point that real funds are involved.
Honestly, from experience, people are generally fine with a multisig being the admin / handling critical operations initially. Yearn started with a 5 of 8 multisig for example IIRC, but the multisig holders were made publicly known for transparency. This will give us some breathing room for development as well, where we can push the governance framework deployment down the line. Maybe tally will have support for Polygon by then.
I'm unsure about (2). Most projects I know launch on eth mainnet, then setup bridging to other chains via anyswap / multichain.xyz. Tokens that are on L2 / other chains seem to stay within that chain...
I really appreciate the pragmatic wisdom in that proposal, @HickupHH3. Unfortunately I am increasingly concerned about using a multisig based on the state of US regulation.
I think we do need to go with an on-chain model from the beginning in order to avoid any doubt about whether we are a decentralized org.
@gpersoon @HickupHH3: I really appreciate the depth you have wrestled with in this so far. Would one of you be willing to take responsibility for reviewing our options for on-chain governance on Polygon and making a proposal of a path forward based on that?
Also! Scott pointed out that $CODE as a token is not in use. (At least there isn't a project listed on coingecko with that symbol.) That is a great one and we should go with that.