Try   HackMD

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, => API 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, => API 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, => API.

With this preconditions we have prepared the EVM for on-chain Governance though the Open Zeppelin Governance Contracts

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

Core

  • IGovernor, => API Interface of the Governor core
  • Governor, => API 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, =>API 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, => API 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, => API 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, => API 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, API Simple voting mechanism with 3 voting options: Against, For and Abstain.

  • GovernorTimelockControl, => API 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, =>API 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.