# Shimmer Open Zeppelin Governor contracts

As a precondition for any Open Zeppelin Governor based Governance system, we need a Governance token with the following property:
- [**ERC20Votes**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Votes.sol), => [API](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20#ERC20Votes) extension. Meaning that we will have to provide an `ERC20wrapper` that wraps our native SMR into the Governance compatible Token.
- Extension of ERC20 to support Compound-like voting and delegation.
- This extension keeps a history (checkpoints) of each account’s vote power. Vote power can be delegated either by calling the delegate function directly, or by providing a signature to be used with delegateBySig. Voting power can be queried through the public accessors getVotes and getPastVotes.
- By default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it requires users to delegate to themselves in order to activate checkpoints and have their voting power tracked.

==The natively used wrapped Shimmer contract in the Shimmer EVM deployed under address `0xBEb654A116aeEf764988DF0C6B4bf67CC869D01b` fullfils this condition.==

- [**Votes**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/governance/utils/Votes.sol), => [API](https://docs.openzeppelin.com/contracts/4.x/api/governance#Votes) This is a base abstract contract that tracks voting units, which are a measure of voting power that can be transferred, and provides a system of vote delegation, where an account can delegate its voting units to a sort of "representative" that will pool delegated voting units from different accounts and can then use it to vote in decisions. In fact, voting units must be delegated in order to count as actual votes, and an account has to delegate those votes to itself if it wishes to participate in decisions and does not have a trusted representative.
This contract is often combined with a token contract such that voting units correspond to token units.

A further precondition for the Governance compatibility is the implementation of a time module, because our variable Block periods permit otherwise an exact determination of time intervalls. This uses the [**`IERC6272` interface**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.9.0/contracts/interfaces/IERC6372.sol), => [API](https://docs.openzeppelin.com/contracts/4.x/api/interfaces#IERC6372).

With this preconditions we have prepared the EVM for on-chain Governance though the Open [Zeppelin Governance Contracts](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/governance)

This Document defines the needed Smartcontracts and configurations for the Shimmer EVM Governance used to secure the Shimmer Community Treasury.

## `Core`

- [**IGovernor**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/governance/IGovernor.sol), => [API](https://docs.openzeppelin.com/contracts/4.x/api/governance#IGovernor) Interface of the `Governor` core
- [**Governor**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/Governor.sol), => [API](https://docs.openzeppelin.com/contracts/4.x/api/governance#Governor) The core contract that contains all the logic and primitives. It is abstract and requires choosing further preconfigured modules for certain functionalities, or to use custom modules.

 - A counting module must implement {quorum}, {_quorumReached}, {_voteSucceeded} and {_countVote}
 - A voting module must implement {_getVotes}
 - Additionally, {votingPeriod} must also be implemented

### `modules:`
- [**GovernorVotes**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorVotes.sol), =>[API](https://docs.openzeppelin.com/contracts/4.x/api/governance#GovernorVotes) Extension of Governor for voting weight extraction from an ERC20Votes token

An important part is the `{quorum}`. The standard Governor expects the useage of:
- [**GovernorVotesQuorumFraction**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/governance/extensions/GovernorVotesQuorumFraction.sol), => [API](https://docs.openzeppelin.com/contracts/4.x/api/governance#GovernorVotesQuorumFraction) Extension of Governor for voting weight extraction from an ERC20Votes token and a quorum expressed as a fraction of the total supply.
- Because our total supply can be vastly fluctuating and depends on the amount of SMR tokens deposited into the EVM (and wrapped into wSMR) we must modify the `GovernorVotesQuorumFraction.sol` contract to use a fixed amount of wSMR tokens as a quorum. This amount must be upgradable through a Governance vote.
- The first value for `quorum` should be set as `45.000.000 wSMR`
- The valid voting options that are counted in the `quorum` calculation shall be the options `For` and `Abstain` taken from the `GovernorCountingSimple.sol` module.

- [**GovernorPreventLateQuorum**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/governance/extensions/GovernorPreventLateQuorum.sol), => [API](https://docs.openzeppelin.com/contracts/4.x/api/governance#GovernorPreventLateQuorum) A module that ensures there is a minimum voting period after quorum is reached. This prevents a large voter from swaying a vote and triggering quorum at the last minute, by ensuring there is always time for other voters to react and try to oppose the decision.
If a vote causes quorum to be reached, the proposal’s voting period may be extended so that it does not end before at least a specified time has passed (the "vote extension" parameter). This parameter can be set through a governance proposal.
- Proposed parameter setting: `24hours`

- [**GovernorSettings**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/governance/extensions/GovernorSettings.sol), => [API](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/governance/extensions/GovernorSettings.sol) Extension of Governor for settings updatable through governance.
- Sets the following parameters:
- `votingDelay()`: Set to `0 days`
- `votingPeriod()`: Set to `7 days`
- `proposalThreshold()`: remove and exchange to only allow whitelisted addresses to propose

- [**GovernorCountingSimple**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/governance/extensions/GovernorCountingSimple.sol), [API](https://docs.openzeppelin.com/contracts/4.x/api/governance#GovernorCountingSimple) Simple voting mechanism with 3 voting options: Against, For and Abstain.
- [**GovernorTimelockControl**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/governance/extensions/GovernorTimelockControl.sol), => [API](https://docs.openzeppelin.com/contracts/4.x/api/governance#GovernorTimelockControl) Extension of Governor that binds the execution process to an instance of TimelockController. This adds a delay, enforced by the TimelockController to all successful proposal (in addition to the voting duration). The Governor needs the proposer (and ideally the executor) roles for the Governor to work properly.
Using this model means the proposal will be operated by the TimelockController and not by the Governor. Thus, the assets and permissions must be attached to the TimelockController. Any asset sent to the Governor will be inaccessible.
- Proposed Timelock intervall: `3 days`
- [**TimelockController**](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/governance/TimelockController.sol), =>[API](https://docs.openzeppelin.com/contracts/4.x/api/governance#TimelockController) Contract module which acts as a timelocked controller. When set as the owner of an Ownable smart contract, it enforces a timelock on all onlyOwner maintenance operations. This gives time for users of the controlled contract to exit before a potentially dangerous maintenance operation is applied.
By default, this contract is self administered, meaning administration tasks have to go through the timelock process. The proposer (resp executor) role is in charge of proposing (resp executing) operations.