The LEND (and AAVE) token can be used in the protocol's decision-making process, ensuring that the protocol evolves and grows in a decentralised manner.
On a technical level, the main components of the Aave Genesis Governance are:
AaveProtoGovernancecontract, which handles most of the logic for voting.
AssetVotingWeightProvidercontract, which whitelists and sets voting weight for assets.
AavePropositionPowercontract, which controls permissions for protocol governance such as registering a new proposal.
GovernanceParamsProvidercontract, which stores the global protocol governance parameters such as the threshold of proposition power needed to register a new proposal.
Genesis Governance proposals have distinct phases:
- 1.Creation: A proposal is created by a user with enough proposition power. In the early stages, this will be the Genesis team. The proposal includes code that will be executed on passing of the proposal.
- 3.Validating: At the end of the
_votingBlocksDuration, if the voting
_thresholdhas been reached,the proposal is moved to the 'Validating' phase with a duration of
- 1.If the
_thresholdhas not been reached, then the proposal will remain in the 'Voting' phase until the
- 2.During the 'Validating' phase, anyone can challenge (and cancel invalid) votes by calling the
challengeVoters()method. Votes are considered invalid if their vote token balance is currently lower than the vote token balance at the time of voting.
- 3.This process, going from 'Validating' and back to 'Voting' can happen a maximum number of
_maxMovesToVotingAllowed, after which it is considered 'Expired' if it has not passed.
- 4.Execution: At the end of
_validatingBlocksDuration, the proposal is resolved and the status is changed to 'Executed'.
- 1.If the votes
_thresholdhas been reached then the
execute()method of the proposal's
_proposalExecutoris called, implementing/executing the governance proposal code.
- 2.If the votes
_thresholdhas not been reached, then no proposal code is executed.
To perform AAVE voting and governance in your integration, the following steps should be followed:
You can fetch the list of proposal IDs a few ways :
- On-chain: use
try...catchpattern to iterate through proposal IDs, starting at index 0
Once you have a list of the proposals, you can query for more proposal data:
- Via our GraphQL: query our subgraph to receive the proposal's details
Other useful methods includes
function submitVoteByVoter(uint256 _proposalId, uint256 _vote, IERC20 _asset)
Submits a vote by the caller.
function cancelVoteByVoter(uint256 _proposalId)
Cancels a vote by the caller.
function challengeVoters(uint256 _proposalId, address calldata _voters)
During the 'Validating' phase, anyone can call this method to challenge and cancel invalid votes. This is to prevent double-voting attacks.
A vote is considered invalid when the voter's current balance of the voting asset is less than the balance of the.same asset at the time of casting their vote.
E.g. Alice has a balance of 100 LEND, votes on Proposal 1, and sends 50 LEND to an exchange before the end of the 'Validating' phase. Her vote would become invalid as her current balance is less than her balance at the time of making the vote.
function getLimitBlockOfProposal(uint256 _proposalId)
Gets the maximum block number that a proposal is potentially 'Resolvable'. If the current block number is greater than this value, then the proposal is 'Invalid'.
function getLeadingChoice(uint256 _proposalId)
Gets the current leading choice in votes, i.e. the current majority of votes.
function getProposalBasicData(uint256 _proposalId)
Gets the basic data of a proposal.
function getVoterData(uint256 _proposalId, address _voterAddress)
Gets the voting data of a particular voter for a proposal ID.
function getVotesData(uint256 _proposalId)
Gets the voting data, i.e. the cumulative votes of each choice, for a given proposal ID.
Returns the address of the