References
Last updated
Last updated
The Timelock contract can modify system parameters, logic, and contracts in a 'time-delayed, opt-out' upgrade pattern. Timelock has a hard-coded minimum delay of 2 days, which is the least amount of notice possible for a governance action. Each proposed action will be published at a minimum of 2 days in the future from the time of announcement. Major upgrades, such as changing the risk system, may have up to a 30 day delay. Timelock is controlled by the governance module; pending and completed governance actions can be monitored on the Timelock Dashboard.
Emitted when an account changes its delegate.
Emitted when a delegate account's vote balance changes.
Emitted when a new proposal is created.
Emitted when a vote has been cast on a proposal.
Emitted when a proposal has been canceled.
Emitted when a proposal has been queued in the Timelock.
Emitted when a proposal has been executed in the Timelock.
Returns the balance of votes for an account as of the current block.
Name | Type | |
---|---|---|
account |
| Address of the account of which to retrieve the number of votes. |
Returns the prior number of votes for an account at a specific block number. The block number passed must be a finalized block or the function will revert.
Name | Type | |
---|---|---|
account |
| Address of the account of which to retrieve the prior number of votes. |
blocknumber |
| The block number at which to retrieve the prior number of votes. |
unnamed |
| The number of prior votes |
Delegate votes from the sender to the delegatee. Users can delegate to 1 address at a time, and the number of votes added to the delegateeâs vote count is equivalent to the balance of PEAK in the userâs account. Votes are delegated from the current block and onward, until the sender delegates again, or transfers their PEA.
Name | Type | |
---|---|---|
delegatee |
| The address to which msg.sender wishes to delegate their votes to. |
Delegate votes from the sender to the delegatee. Users can delegate to 1 address at a time, and the number of votes added to the delegateeâs vote count is equivalent to the balance of PEAK in the userâs account. Votes are delegated from the current block and onward, until the sender delegates again, or transfers their PEAK.
Name | Type | |
---|---|---|
delegatee |
| The address to which msg.sender wishis to delegate their vote to |
nonce |
| The contract state required to match the signature. This can be retrieved from the contractâs public nonces mapping |
expiry |
| The time when the signature expires. A block timestamp in seconds since the unix epoch. |
v |
| The recovery byte of the signature. |
r |
| Half of the ECDSA signature pair. |
s |
| Half of the ECDSA signature pair. |
Returns the minimum number of votes required for a proposal to succeed.
Returns the minimum number of votes required for an account to create a proposal.
Returns the maximum number of actions that can be included in a proposal. Actions are functions calls that will be made when a proposal succeeds and executes.
Returns the number of blocks to wait before voting on a proposal may begin. This value is added to the current block number when a proposal is created.
Returns the duration of voting on a proposal, in blocks.
Gets the actions of a selected proposal. Pass a proposal ID and get the targets, values, signatures and calldatas of that proposal.
Name | Type | |
---|---|---|
proposalId |
| ID of the proposal |
Returns:
Array of addresses of contracts the proposal calls.
Array of unsigned integers the proposal uses as values.
Array of strings of the proposalâs signatures.
Array of calldata bytes of the proposal.
Returns a proposal ballot receipt of a given voter.
Name | Type | |
---|---|---|
proposalId |
| ID of the proposal in which to get a voterâs ballot receipt. |
voter |
| Address of the account of a proposal voter. |
Receipt |
| A Receipt struct for the ballot of the voter address. |
Returns enum of type ProposalState, possible types are: -Pending -Active -Canceled -Defeated -Succeeded -Queued -Expired -andExecuted
Name | Type | |
---|---|---|
proposalId |
| ID of the proposal |
Creates a Proposal to change the protocol.
Proposals will be voted on by delegated voters. If there is sufficient support before the voting period ends, the proposal shall be automatically enacted. Enacted proposals are queued and executed in the Timelock contract.
The sender must hold more PEAK than the current proposal threshold (proposalThreshold()) as of the immediately previous block. The proposal can have up to 10 actions (based on proposalMaxOperations()).
The proposer cannot create another proposal if they currently have a pending or active proposal. It is not possible to queue two identical actions in the same block (due to a restriction in the Timelock), therefore actions in a single proposal must be unique, and unique proposals that share an identical action must be queued in different blocks.
Name | Type | |
---|---|---|
targets |
| The ordered list of target addresses for calls to be made during proposal execution. This array must be the same length as all other array parameters in this function. |
values |
| The ordered list of values (i.e. msg.value) to be passed to the calls made during proposal execution. This array must be the same length as all other array parameters in this function |
signatures |
| The ordered list of function signatures to be passed during execution. This array must be the same length as all other array parameters in this function. |
calldatas |
| The ordered list of data to be passed to each individual function call during proposal execution. This array must be the same length as all other array parameters in this function. |
description |
| A human readable description of the proposal and the changes it will enact. |
Unnamed |
| Returns ID of the new proposal |
After a proposal has succeeded, any address can call the queue method to move the proposal into the Timelock queue. A proposal can only be queued if it has succeeded.
Name | Type | |
---|---|---|
proposalId |
| ID of a given successful proposal |
After the Timelock delay period, any account may invoke the execute method to apply the changes from the proposal to the target contracts. This will invoke each of the actions described in the proposal. This function is payable so the Timelock contract can invoke payable functions that were selected in the proposal.
Name | Type | |
---|---|---|
proposalId |
| ID of a given successful proposal |
Cancel a proposal that has not yet been executed. The Guardian is the only one who may execute this unless the proposer does not maintain the delegates required to create a proposal. If the proposer does not have more delegates than the proposal threshold, anyone can cancel the proposal.
Name | Type | |
---|---|---|
proposalId |
| ID of a proposal to cancel |
Cast a vote on a proposal. The account's voting weight is determined by it's number of delegated votes at the time the proposal becomes active.
Name | Type | |
---|---|---|
proposalId |
| ID of a given successful proposal |
support |
| A boolean of true for 'yes' or false for 'no' on the proposal vote. |
Cast a vote on a proposal. The account's voting weight is determined its number of delegated votes at the time the proposal became active. This method has the same purpose as Cast Vote, but instead enables offline signatures to participate in governance voting. For more details on how to create an offline signature, review EIP-712.
Name | Type | |
---|---|---|
proposalId |
| ID of a given successful proposal |
support |
| A boolean of true for 'yes' or false for 'no' on the proposal vote. |
expiry |
| The time when the signature expires. A block timestamp in seconds since the unix epoch. |
v |
| The recovery byte of the signature. |
r |
| Half of the ECDSA signature pair. |
s |
| Half of the ECDSA signature pair. |