# OZ governance

## functions
### COUNTING_MODE()
計票方式
2 個標準鍵：support和quorum。
### relay
將事務或函數調用中繼到任意目標。在治理執行者是治理者本身以外的某個合約的情況下，例如使用時間鎖時，可以在治理提案中調用此函數來恢復錯誤發送到治理者合約的代幣或以太幣。請注意，如果執行者只是管理者本身，則使用 ofrelay是多餘的。
### GovernorVotes
Governor從令牌中提取投票權重的擴展ERC20Votes，或從 v4.5 開始的ERC721Votes令牌。
### GovernorTimelockControl
的擴展Governor將執行過程綁定到TimelockController. 這增加了延遲，由TimelockController所有成功的提案強制執行（除了投票持續時間）。Governor需要提議者（理想情況下是執行者）角色才能 Governor正常工作。

使用這種模式意味著提案將由TimelockController而不是由Governor. 因此，資產和權限必須附加到TimelockController. 發送到的任何資產Governor都將無法訪問。

將 TimelockController 設置為除了管理者之外還有其他提議者是非常冒險的，因為它授予他們必須被信任或已知不使用的權力：1）通過時間鎖對他們可用的功能，以及 2）批准的治理提案onlyGovernance可以relay被他們阻止，有效地執行拒絕服務攻擊。這種風險將在未來的版本中得到緩解。
### GovernorTimelockCompound
其擴展Governor將執行過程綁定到復合時間鎖。這增加了延遲，由外部時間鎖強制所有成功的提案（除了投票持續時間）。需要成為時間鎖的Governor管理員才能執行任何操作。公開的、不受限制 GovernorTimelockCompound.acceptAdmin的可以接受時間鎖的所有權。

使用這種模式意味著提案將由TimelockController而不是由Governor. 因此，資產和權限必須附加到TimelockController. 發送到的任何資產Governor都將無法訪問。
### GovernorSettings
擴展Governor可通過治理更新的設置。
### GovernorPreventLateQuorum
確保達到法定人數後有最短投票期的模塊。通過確保其他選民總是有時間做出反應並試圖反對該決定，這可以防止大量選民在最後一刻動搖投票並觸發法定人數。

如果投票導致達到法定人數，則提案的投票期可能會延長，以便在至少給定數量的塊通過之前它不會結束（“投票延期”參數）。該參數可以由治理執行者設置（例如通過治理提案）。

### GovernorCompatibilityBravo
Compatibility layer that implements GovernorBravo compatibility on to of Governor.

This compatibility layer includes a voting system and requires a IGovernorTimelock compatible module to be added through inheritance. It does not include token bindings, not does it include any variable upgrade patterns.
最齊全
### Deprecated
GovernorProposalThreshold
### Utils
#### Votes
跟踪投票單元的基本抽象合約，投票單元是可以轉移的投票權的衡量標準，並提供投票委託系統，其中一個帳戶可以將其投票單元委託給一種“代表”，該“代表”將匯集委託來自不同賬戶的投票單元，然後可以使用它來投票決定。事實上，投票單元必須被委託才能算作實際投票，如果一個賬戶希望參與決策並且沒有受信任的代表，則必須將這些投票委託給自己。

該合約通常與代幣合約相結合，使得投票單位對應於代幣單位。例如，請參閱ERC721Votes。

代表投票的完整歷史記錄在鏈上進行跟踪，以便治理協議可以將投票視為在特定區塊號上分配，以防止閃貸和雙重投票。選擇加入委託系統使這種歷史跟踪的成本成為可選的。

使用此模塊時，派生合約必須實現_getVotingUnits（例如，使其返回 ERC721.balanceOf），並且可以_transferVotingUnits用來跟踪這些單位分佈的變化（在前面的示例中，它將包含在 中ERC721._beforeTokenTransfer）。

### Terminology
#### Operation:
A transaction (or a set of transactions) that is the subject of the timelock. It has to be scheduled by a proposer and executed by an executor. The timelock enforces a minimum delay between the proposition and the execution (see operation lifecycle). If the operation contains multiple transactions (batch mode), they are executed atomically. Operations are identified by the hash of their content.

#### Operation status:

Unset: An operation that is not part of the timelock mechanism.
Pending: An operation that has been scheduled, before the timer expires.
Ready: An operation that has been scheduled, after the timer expires.
Done: An operation that has been executed.
Predecessor: An (optional) dependency between operations. An operation can depend on another operation (its predecessor), forcing the execution order of these two operations.

#### Role:

Admin: An address (smart contract or EOA) that is in charge of granting the roles of Proposer and Executor.

Proposer: An address (smart contract or EOA) that is in charge of scheduling (and cancelling) operations.

Executor: An address (smart contract or EOA) that is in charge of executing operations once the timelock has expired. This role can be given to the zero address to allow anyone to execute operations.

### Operation structure
Operation executed by the TimelockController can contain one or multiple subsequent calls. Depending on whether you need to multiple calls to be executed atomically, you can either use simple or batched operations.

Both operations contain:

Target, the address of the smart contract that the timelock should operate on.

Value, in wei, that should be sent with the transaction. Most of the time this will be 0. Ether can be deposited before-end or passed along when executing the transaction.

Data, containing the encoded function selector and parameters of the call. This can be produced using a number of tools. For example, a maintenance operation granting role ROLE to ACCOUNT can be encode using web3js as follows:

const data = timelock.contract.methods.grantRole(ROLE, ACCOUNT).encodeABI()

Predecessor, that specifies a dependency between operations. This dependency is optional. Use bytes32(0) if the operation does not have any dependency.

Salt, used to disambiguate two otherwise identical operations. This can be any random value.

In the case of batched operations, target, value and data are specified as arrays, which must be of the same length.

### Operation lifecycle
Operation lifecycle
Timelocked operations are identified by a unique id (their hash) and follow a specific lifecycle:

Unset → Pending → Pending + Ready → Done

By calling schedule (or scheduleBatch), a proposer moves the operation from the Unset to the Pending state. This starts a timer that must be longer than the minimum delay. The timer expires at a timestamp accessible through the getTimestamp method.

Once the timer expires, the operation automatically gets the Ready state. At this point, it can be executed.

By calling execute (or executeBatch), an executor triggers the operation’s underlying transactions and moves it to the Done state. If the operation has a predecessor, it has to be in the Done state for this transition to succeed.

cancel allows proposers to cancel any Pending operation. This resets the operation to the Unset state. It is thus possible for a proposer to re-schedule an operation that has been cancelled. In this case, the timer restarts when the operation is re-scheduled.

Operations status can be queried using the functions:
* isOperationPending(bytes32)
* isOperationReady(bytes32
* isOperationDone(bytes32)

### Roles
#### Admin
管理員負責管理提議者和執行者。對於要自治的時間鎖，這個角色應該只賦予時間鎖本身。在部署時，時間鎖和部署者都有這個角色。在進一步的配置和測試之後，部署者可以放棄這個角色，這樣所有進一步的維護操作都必須經過時間鎖定過程。
#### Proposer
提議者負責調度（和取消）操作。這是一個關鍵角色，應該賦予管理實體。這可以是 EOA、多重簽名或 DAO。
#### Executor
一旦時間鎖到期，執行者負責執行提議者安排的操作。邏輯規定，作為提議者的多重簽名或 DAO 也應該是執行者，以保證已調度的操作最終將被執行。但是，擁有額外的執行者可以降低成本（執行交易不需要由提議它的多重簽名或 DAO 驗證），同時確保負責執行的人不會觸發提議者尚未安排的操作。或者，可以通過將執行者角色授予零地址來允許任何地址在時間鎖到期後執行提案。