Deploy "Unlock Protocol Governor" contract

[julien51]

Now that our UDT token has been upgraded to support the requirements for governance, let's deploy the Governor contract!

OpenZeppelin's docs are there: https://610b0fed9a970b00086554ba--openzeppelin-contracts-docs.netlify.app/contracts/4.x/governance We can also use their wizard: https://deploy-preview-45--openzeppelin-contracts-wizard.netlify.app/#governor

Name: Unlock Protocol Governor Voting delay: let's identify the most common value in popular gov contracts Voting Period: same Proposal Threshold: Same Quorum: Since the pre-mined tokens are still not assigned/locked, I suggest we use a fixed value that we can increase later? How do other projects do that?

As for other params, I am not 100% sure I have all the required context. Would you be able to clarify their role and the pros/cons @clemsos @Amxx ?

Thanks!

[clemsos]

For reference, some existing Governor contracts

• UniSwap https://etherscan.io/address/0xc4e172459f1e7939d522503b81afaac1014ce6f6#code
• Radicle https://etherscan.io/address/0x690e775361AD66D1c4A25d89da9fCd639F5198eD#code
• Fei https://etherscan.io/address/0xe087f94c3081e1832dc7a22b48c6f2b5faae579b#code

[clemsos]

Voting delay: let's identify the most common value in popular gov contracts

This can be kept low (1 block) so people can start voting once the proposal is posted

Voting Period: same

Seems to span from half a day to a week in different projects. It depends on the reactivity expected from the community - and the communication around the votes. A shorter time span will imply more communication and "campaigning" ahead to announce. 1 week seems good for starter, so anyone as time to understand how things work and then cast as vote. Once the governance process for announcements and voting is more streamlined it can be lowered.

Proposal Threshold: Same Quorum: Since the pre-mined tokens are still not assigned/locked, I suggest we use a fixed value that we can increase later? How do other projects do that?

For those two, not sure how to come up with a relevant value here. Threshold can be sth like .25% of the circulating supply and quorum around 4%. So that will be (currentSupply - preMined) * .25%

[julien51]

Awesome! Thanks for the clarifications!

Voting delay: 1 block is fine! Voting period: agreed that 1 week is probably fine!

I am not sure I fully understand your last point about quorum :) When looking at the current holders:

• the first address is the company's multisig and we should not expect it to vote.
• the 2nd and 3rd addresses are bridges to xDAI and Polygon, so no votes.
• the 5th is Sablier, so no votes.
• the 6th is a company's wallet, and we should not expect to vote.
• 7th and 8th are pools, so, even though there could be votes, I don't expect them to get fully drained anytime soon.

In practice, this means 890,099 + 30,011 + 30,011 + 2,388 + 2,304 + 1,834 + 1,163 = 957,810 tokens will not (be able to?) vote. Which means that at most, we would get at most 42,687 votes in the current state of supply. Additionally, we have currently about 4,100 holders, which gives us an average holder of 1,000 tokens, but only 63 people have more than 100 tokens and altogether they account for 54.48% of the supply. (The median holder has less than 1.5 UDT)

One whale owns 21% of the circulating. As a consequence, I would suggest using a quorum that is about 30% of 42,687 or about 15,000 tokens. What do you think?

[clemsos]

Yep, 15k seems a good compromise then. Should we make this calculation apparent somewhere?

[julien51]

That's a good question. What about the docs? https://docs.unlock-protocol.com/governance/unlock-dao

[clemsos]

Sounds good. Also maybe useful to set a condition on which the quorum could be reevaluated such as "if the distribution were to change drastically"