---
# System prepended metadata

title: Governor v2

---

# Governor v2

Foundation Mission aka 'RFP'

## Links

- OP Foundation Mission: https://github.com/ethereum-optimism/ecosystem-contributions/issues/64
- Governor v1: https://optimistic.etherscan.io/address/0xcdf27f107725988f2261ce2256bdfcde8b382b10#code 
- OZ contract: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/Governor.sol 
- Collective trust tiers: https://gov.optimism.io/t/collective-trust-tiers/5877#eagle-tier-eligible-to-receive-between-350k-op-and-1m-op-4 

## Submision form (draft)

Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Optimism Foundation may reach out using the contact info provided to request more information as necessary.

Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier

- Alliance Lead: [Julien Béranger]([@julienbrg](https://github.com/julienbrg)) ([WH3C](https://w3hc.org/))
- Contact info: [Element](https://matrix.to/#/@julienbrg:matrix.org), [Telegram](https://t.me/julienbrg), [Twitter](https://twitter.com/julienbrg), [Discord](https://discord.com/invite/uSxzJp3J76), [LinkedIn](https://www.linkedin.com/in/julienberanger/), [Email](https://mailto:julien@strat.cc)
- L2 recipient address: [0x27292E1a901E3E0bE7d144aDba4CAD07da2d8a42](https://optimistic.etherscan.io/address/0x27292E1a901E3E0bE7d144aDba4CAD07da2d8a42)
- Please list the members of your Alliance and link to any previous work: 
    - Members: [Julien](https://github.com/julienbrg), [Olivier](https://github.com/fernandezOli), [Bertux](https://github.com/bertux)
    - Previous works: [Gov](https://app.optimism.io/retropgf-discovery/0xa30189949cD8F662582b10eB6E353374419EDf67), [ERC-5560](https://app.optimism.io/retropgf-discovery/0x5874D5D530D1f969FD962579c445A0f3A8682D48) (both recipients of RetroPGF 2)

**What makes your Alliance best-suited to execute this Mission?**

- The W3HC (Web3 Hackers Collective) developed a DAO framework called Gov, which is a combination of ERC-721s and the Governor contract (you can deploy your DAO to Optimism Mainnet [right here](https://gov-deployer.on.fleek.co/)). So we're extremely familiar with the Governor contract.
- We're a team of three experienced developers. We've been working together for years on several projects. I personnally started to work on DAOs many years ago (2016).
- We're in contact with several different specialists in their fields (UX, security audits, and legal).

**Please describe your proposed solution based on the above Solution Criteria (if applicable):**

- Partial delegation
    - Instead of allowing people to delegate to only one delegate as it now on v1, we will allow token holders to split their voting power to multiple delegates.
    - This requires a modification in several functions of the [Votes contract](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/utils/Votes.sol) and any other contracts depending on it. 

- Accurate votable supply quorum calculation
    - inclure le quorum dans la proposal (chaque proposal a son propre quorum)
    - on ajoute une notion de “total votable supply” --> on exclut ceux qui n'ont pas delegué

- Support for different proposal types (a) et (b)
    - Super relevant
    - Chaque type de proposal, on le quorum et le  approval threshold changent (en fonction du type)

Types: 

* Governance Fund
* Protocol Upgrade
* Inflation Adjustment
* Director Removal
* Treasury Appropriations
* Rights Protections

https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types

Support for different proposal types: the contract should support different proposal types that correspond to the proposal types in the Optimism Operating Manual, each of which may have a different quorum and approval threshold. In addition, the contract should include a straightforward path to (a) add new proposal types, and (b) manage proposal types’ quorums and approval thresholds.

- Support for different vote types
    - ça touche encore au même module de vote
    - deux demandes en même temps
    - implem du vote au jugement majoritaire (mono ou multi réponse)

Support for different vote types: The contract should support different vote types beyond the current “simple vote” (yes / no / abstain). These should include single choice voting (i.e. for use in an election), and approval voting (i.e. for use in approving Missions), as well as an approach for extensibility such that other voting strategies can be added in the future.

- Integrate new contract functionality into a voting UI
    - On a déjà une interface, on peut faire tester tout le monde, etc

**Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:**

- 1 mois, 2 mois, etc
- 1 mois beta testers
- 1 mois audit
- 2 mois de plus au cas où

The plan is to

- Spin up a Governor-compatible UI (this we already have) to 
- Get the detailed specifications validated by everyone (August 1st)
- 


**Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:**

- Detailed specs delivered
- All requested features delivered (passing unit tests)
- Beta-testing completed
- Security audit released

**Please list any additional support your team would require to execute this mission (financial, technical, etc.):**

We would almost entirely cover the development of the Solidity contracts and UI, but we already know that we will need:
- External audit
- A group of beta testers

**Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)**

We're a small hackers collective without any business model whatsoever for now, so a $72k USD eq. up-front cash grant covering 6 months of work would allow us work in the best conditions. 

...

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

 I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
 I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
 I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
 I confirm that I have read and understand the grant policies
 I understand that I will be expected to following the public grant reporting requirements outlined here
-- end of application --

## Ideas

**Partial delegation**: the ability for any address to delegate only a portion of their tokens to an address, or for an address to delegate multiple portions of their tokens to multiple addresses.

... 

**Accurate votable supply quorum calculation**: quorum for each vote should be calculated as a portion of the “total votable supply,” the total number of OP currently delegated to vote. (Today, the quorum for each vote is set manually on the contract.)

...

**Support for different proposal types**: the contract should support different proposal types that correspond to the proposal types in the Optimism Operating Manual, each of which may have a different quorum and approval threshold. In addition, the contract should include a straightforward path to (a) add new proposal types, and (b) manage proposal types’ quorums and approval thresholds.

...

**Support for different vote types**: The contract should support different vote types beyond the current “simple vote” (yes / no / abstain). These should include single choice voting (i.e. for use in an election), and approval voting (i.e. for use in approving Missions), as well as an approach for extensibility such that other voting strategies can be added in the future.

...

**Integrate new contract functionality into a voting UI**: The contract improvements above should be usable by governance participants with varying degrees of technical expertise. An ideal proposal includes a plan to surface this new functionality to voters in a straightforward UI.