Governance
Introduction
The Paribus protocol is governed and upgraded by PBX token-holders, using three distinct components; the PBX token, governance module (Governor Delegator), and Timelock. Together, these contracts allow the community to propose, vote, and implement changes through the administrative functions of a pToken or the Comptroller. Proposals can modify system parameters, support new markets, or add entirely new functionality to the protocol.
Holders of PBX tokens may stake their tokens in order to get voting rights. Proposals for governance may be made by addresses having at least 10.000.000 voting power.
When a governance proposal is created, it enters a 2 day review period, after which the voting begins. Voting lasts for 5 days; if a majority, and at least 100.000.000 votes are cast for the proposal, it is queued in the Timelock, and can be implemented threedays later. In total, any change to the protocol takes at least 10 days.
PBX
PBX is an ERC-20 token that allows the owner to delegate voting rights to themselve by locking it up for a certain period by using the Governor Delegator.
Key Events
ProposalCreated(uint id, address proposer, address[] targets, uint[] values, string[] signatures, bytes[] calldatas, uint startBlock, uint endBlock, string title, string description)
VoteCast(address voter, uint proposalId, bool support, uint votes, string reason)
ProposalCanceled(uint id)
ProposalQueued(uint id, uint eta)
ProposalExecuted(uint id)
NewPBXStake(address indexed account, uint PBXAmount, uint startsAtTimestamp, uint endsAtTimestamp)
PBXWithdrawal(address indexed account, uint PBXAmount, uint startsAtTimestamp, uint endsAtTimestamp)
PBXRewardCampaignStarted(uint startsAtTimestamp, uint endsAtTimestamp, uint PBXRewardsAmount)
Governor Delegator
Governor Delegator is the governance module of the protocol; it allows addresses with more than 10.000.000 voting power to propose changes to the protocol. Addresses that held voting weight, at the start of the proposal, invoked through the getpriorvotes function, can submit their votes during a 3 day voting period. If a majority, and at least 400,000 votes are cast for the proposal, it is queued in the Timelock, and can be implemented after 2 days.
Start PBX Reward campaign
Launch PBX Rewards Campaign that is distributed among activate participants of the governance.
Governor Delegator
endsAtTimestamp
: PBX Rewards Campaign end time.PBXRewardsAmount
: Total PBX amount to be distributedRETURN
: No return, reverts on error.
Solidity
Web3 1.2.6
Calculate PBX Reward
Calculate the amount of PBX that a given account has pending from participating in Governance during an on-going campaign
Governor Delegator
account
: Account to check for pending rewardsRETURN
: The amount of pending PBX for withdraw
Solidity
Web3 1.2.6
Withdraw PBX Reward
Withdraw the PBX that a given account has pending from participating in Governance during an on-going campaign
Governor Delegator
RETURN
: No return, reverts on error.
Solidity
Web3 1.2.6
Stake PBX
Stake PBX to receive votes. Votes received depends on the staking period.
Governor Delegator
addPBXAmount
: PBX amount to be transferred. Can be 0 when updating existing stakePeriodLen only, without changing the amountnewStakePeriodLenSecs
: Stake period length in seconds. Use 0 when updating existing stake without changing existing stakePeriodLenRETURN
: No return, reverts on error.
Solidity
Web3 1.2.6
Withdraw PBX Stake
Withdraw staked PBX after the lockup period finished
Governor Delegator
RETURN
: No return, reverts on error.
Solidity
Web3 1.2.6
Get Current Votes
Gets the balance of votes for an account as of the current block.
PBX
account
: Address of the account in which to retrieve the number of votes.RETURN
: The number of votes (integer).
Solidity
Web3 1.2.6
Get Hypothetical Votes
Get hypothetical number of votes for a given account after staking PBX.
PBX
account
: Address of the account in which to retrieve the number of votes.addPBXAmount
: New stake amount. Can be 0 when updating existing stakePeriodLen only, without changing the amountnewStakePeriodLenSecs
: New stake period length in blocks. Use 0 when updating existing stake without changing existing stakePeriodLenRETURN
: The number of votes (integer).
Solidity
Web3 1.2.6
Quorum Votes
The required minimum number of votes in support of a proposal for it to succeed.
Governor Delegator
RETURN
: The minimum number of votes required for a proposal to succeed.
Solidity
Web3 1.2.6
Proposal Threshold
The minimum number of votes required for an account to create a proposal. This can be changed through governance.
Governor Delegator
RETURN
: The minimum number of votes required for an account to create a proposal.
Solidity
Web3 1.2.6
Proposal Max Operations
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.
Governor Delegator
RETURN
: The maximum number of actions that can be included in a proposal.
Solidity
Web3 1.2.6
Voting Delay
The number of Ethereum blocks to wait before voting on a proposal may begin. This value is added to the current block number when a proposal is created. This can be changed through governance.
MINIMUM_DELAY
: 2 daysMAXIMUM_DELAY
: 30 days
Governor Delegator
RETURN
: Number of blocks to wait before voting on a proposal may begin.
Solidity
Web3 1.2.6
Voting Period
The duration of voting on a proposal, in Ethereum blocks. This can be changed through governance.
Governor Delegator
RETURN
: The duration of voting on a proposal, in Ethereum blocks.
Solidity
Web3 1.2.6
Grace Period
The duration after which a queued proposal becomes invalid.
GRACE_PERIOD
: 14 days
Propose
Create a Proposal to change the protocol. E.g., A proposal can set a cToken's interest rate model or risk parameters on the Comptroller. 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 Compound Timelock contract.
The sender must hold more PBX 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.
Governor Delegator
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.RETURN
: The ID of the newly created proposal.
Solidity
Web3 1.2.6
Queue
After a proposal has succeeded, it is moved into the Timelock waiting period using this function. The waiting period (e.g. 2 days) begins when this function is called. The queue function can be called by any Ethereum address.
Governor Delegator
proposalId
: ID of a proposal that has succeeded.RETURN
: No return, reverts on error.
Solidity
Web3 1.2.6
Execute
After the Timelock waiting period has elapsed, a proposal can be executed using this function, which applies the proposal changes to the target contracts. This will invoke each of the actions described in the proposal. The execute function can be called by any Ethereum address. Note: this function is payable, so the Timelock contract can invoke payable functions that were selected in the proposal.
Governor Delegator
proposalId
: ID of a succeeded proposal to execute.RETURN
: No return, reverts on error.
Solidity
Web3 1.2.6
Cancel
A proposal is eligible to be cancelled at any time prior to its execution, including while queued in the Timelock, using this function.
The cancel function can be called by the proposal creator, or any Ethereum address, if the proposal creator fails to maintain more delegated votes than the proposal threshold (e.g. 25,000).
Governor Delegator
proposalId
: ID of a proposal to cancel. The proposal cannot have already been executed.RETURN
: No return, reverts on error.
Solidity
Web3 1.2.6
Get Actions
Gets the actions of a selected proposal. Pass a proposal ID and get the targets, values, signatures and calldatas of that proposal.
Governor Delegator
proposalId
: ID of a proposal in which to get its actions.RETURN
: Reverts if the proposal ID is invalid. If successful, the following 4 references are returned.
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.
Solidity
Web3 1.2.6
Get Receipt
Gets a proposal ballot receipt of the indicated voter.
Governor Delegator
proposalId
: ID of the proposal in which to get a voter’s ballot receipt.voter
: Address of the account of a proposal voter.RETURN
: Reverts on error. If successful, returns a Receipt struct for the ballot of the voter address.
Solidity
Web3 1.2.6
State
Gets the proposal state for the specified proposal. The return value, ProposalState
is an enumerated type defined in the Governor Delegator contract.
Governor Delegator
proposalId
: ID of a proposal in which to get its state.RETURN
: Enumerated type ProposalState. The types are Pending, Active, Canceled, Defeated, Succeeded, Queued, Expired, and Executed.
Solidity
Web3 1.2.6
Cast Vote
Cast a vote on a proposal. The account's voting weight is determined by the number of votes the account had delegated to it at the time the proposal state became active.
Governor Delegator
proposalId
: ID of a proposal in which to cast a vote.support
: An integer of 0 for against, 1 for in-favor, and 2 for abstain.RETURN
: No return, reverts on error.
Solidity
Web3 1.2.6
Cast Vote With Reason
Cast a vote on a proposal with a reason attached to the vote.
Governor Delegator
proposalId
: ID of a proposal in which to cast a vote.support
: An integer of 0 for against, 1 for in-favor, and 2 for abstain.reason
: A string containing the voter's reason for their vote selection.RETURN
: No return, reverts on error.
Solidity
Web3 1.2.6
Timelock
Each protocol contract is controlled by the Timelock contract, which can modify system parameters, logic, and contracts in a 'time-delayed, opt-out' upgrade pattern. The Timelock has a hard-coded minimum delay which is the least amount of notice possible for a governance action. The Timelock contract queues and executes proposals that have passed a Governance vote.
Pause Guardian
The Comptroller contract designates a Pause Guardian address capable of disabling protocol functionality. Used only in the event of an unforeseen vulnerability, the Pause Guardian has one and only one ability: to disable a select set of functions: Mint, Borrow, Transfer, and Liquidate. The Pause Guardian cannot unpause an action, nor can it ever prevent users from calling Redeem, or Repay Borrow to close positions and exit the protocol. PBX token-holders designate the Pause Guardian address, which is held by the Community Multi-Sig.
Last updated