When you lend or borrow through a decentralized finance (DeFi) protocol, your interest rate and borrowing limit can change while the position stays open. Changes to collateral rules can affect it too. Onchain governance gives token holders a public process for proposing changes, voting on them, and having smart contracts apply the result.
Aave governance is that process for the Aave lending protocol: holders propose a change, vote on it, and let the result execute onchain after a public waiting period. Under Aave Governance v3, a Level 1 proposal needs at least 80,000 AAVE in proposal power and waits through a 1-day cooldown before it opens for a 3-day vote (source: Aave DAO, Governance.sol).
The process matters to you whether you hold AAVE, borrow on Aave, or only trade the token. A passed proposal can change the markets of the Aave lending protocol you use as soon as its waiting period ends.
What is Aave governance?
Aave governance is the system through which AAVE, stkAAVE, and aAAVE holders on Ethereum mainnet, along with the delegates they choose, approve changes to the Aave Protocol. It runs from forum debate and offchain polls to onchain votes and smart-contract execution. It can change listings, risk settings, incentives, and deployments on new networks.
A decentralized autonomous organization (DAO) is an organization its members own together. Rules written into smart contracts, along with decisions made by proposal and vote, take the place of a chief executive who could spend funds at will (source: ethereum.org, What is a DAO?). The Aave DAO follows that model. Token holders and contributors steer the protocol through proposals, discussion, and votes, with approved changes carried out by smart contracts that start on Ethereum mainnet (source: Aave, Governance).
Several groups hold different parts of that power. Delegates vote with voting power that other holders have entrusted to them. Service providers do specialist work for the DAO, with Llamarisk on risk, Certora on security, Tokenlogic on finance, and Aave Labs on development. The split between Aave Labs and AAVE holders follows from that list. Aave Labs appears on it as the development provider. Like any other address, it needs voting power from AAVE, stkAAVE, or aAAVE to sway a vote (source: Aave, Governance).
Stewards hold delegated control over specific protocol parameters, which lets the DAO respond to market moves without a full vote for every small adjustment. The Risk Steward can raise a market's supply cap or borrow cap by up to 50%, with a change frequency of 5 days. The GHO Aave Steward can move the borrow cap of GHO, Aave's stablecoin, up or down by as much as 100% (source: Aave, Governance). Anything outside those ranges still has to go through a full proposal and vote.
From forum idea to onchain AIP
Most binding Aave changes begin as a post on the Aave Governance Forum and pass through two offchain polls before anyone pays gas to create an onchain Aave Improvement Proposal (AIP). Those early stages cost nothing to vote in, so the community can fix the scope of an idea while rewriting it is still cheap.
The sequence has four steps, and each one narrows the idea. A proposal starts on the forum, where community feedback reshapes it. It then moves to a TEMP CHECK on the Aave Snapshot space, which measures whether enough holders want to continue and needs no detailed technical specification yet. If that check passes, the proposal becomes an Aave Request for Final Comments (ARFC). Service providers and community members test how it would affect the protocol, and a second Snapshot vote follows. The final step is the AIP itself, a formal onchain submission sent mainly through governance contracts on Ethereum mainnet. It has two parts: metadata stored on the InterPlanetary File System (IPFS) and a contract payload (source: Aave, Governance).
Both Snapshot polls last three days and are non-binding, which means they gauge sentiment while leaving every payload unqueued (source: Aave, Governance). Snapshot is an offchain voting platform that lets DAOs and DeFi protocols hold polls without charging voters gas fees (source: Snapshot, What is Snapshot?). A strong Snapshot result tells an author that the idea has support. The binding decision comes later, when an onchain AIP has to clear the thresholds written into the governance contracts.
Some routine changes take a shorter path. Aave keeps standard frameworks for onboarding a new asset, deploying the protocol on a new chain, adding emission admins to reserves, and updating caps. The Caps Update Framework routes cap changes and reserve freezes straight to an AIP so the DAO can respond quickly to market risk. The broader Direct-to-AIP Framework lets certain actions skip the TEMP CHECK and ARFC votes, provided an ARFC post goes up on the forum before the AIP is created (source: Aave, Governance).
How Governance v3 voting works
Governance v3 keeps every voting balance on Ethereum mainnet and lets each proposal collect its votes on a cheaper Voting Network, such as Polygon POS or Avalanche C-Chain. Your tokens stay where they are, because the Voting Network verifies your Ethereum balance with a cryptographic proof before it counts your vote.
BGD Labs built Aave Governance v3, the smart-contract system Aave uses to create and vote on proposals and to execute the approved ones across several networks (source: Aave DAO, aave-governance-v3 repository). The system has three parts that match the life of a proposal. Ethereum mainnet is the Core Network, where voting power is counted and proposals are validated. Voting Networks host the ballots, with Ethereum itself kept as a backup voting network. Execution Networks are where payloads are registered before a proposal and run after it passes. That group takes in every Voting Network as well as the Core Network (source: Aave, Governance).
Your voting power is the sum of three balances on Ethereum mainnet. They are AAVE, stkAAVE (AAVE staked in the Safety Module), and aAAVE (the aToken, or deposit token, you receive for supplying AAVE to the Ethereum V3 market). Each of those tokens carries two separate powers: proposal power for creating proposals and voting power for casting votes. You can delegate the two together or hand each one to a different Ethereum address (source: Aave, Governance). Because stkAAVE counts toward that sum, staking AAVE for stkAAVE keeps your governance power while the tokens sit in the Safety Module.
When a vote is activated, the system records the hash of the Ethereum block just before activation, which fixes everyone's balances and delegations at that moment. It sends that hash to the chosen Voting Network through the Aave Delivery Infrastructure (a.DI), the cross-chain messaging system Aave uses. To vote, you submit your balance at that block together with a storage proof, a cryptographic proof that the balance is recorded in Ethereum's state at that block. The Voting Machine contract then checks the proof and rejects any double vote. Governance interfaces such as the Aave Labs app and Boardroom handle that step when you vote with AAVE. An aave-cli tool can also generate the proof parameters for anyone voting directly against the contracts (source: Aave, Governance).
Level 1 and Level 2 thresholds
Every Aave proposal is assigned an access level, and each level sets its own minimum proposal power, cooldown, voting period, minimum YES vote, and required margin of YES over NO. Level 1 is the access level for most market changes, while Level 2 covers changes to governance itself and carries a much higher bar.
The current voting configuration for each access level is as follows (source: Aave DAO, Governance.sol):
| Access level | Ethereum executor | Min proposal power | Cooldown before vote | Voting duration | YES threshold | YES minus NO margin |
|---|---|---|---|---|---|---|
| Level 1 | Short executor | 80,000 AAVE | 1 day | 3 days | 320,000 AAVE | 80,000 AAVE |
| Level 2 | Long executor | 200,000 AAVE | 1 day | 10 days | 1,040,000 AAVE | 1,040,000 AAVE |
On Ethereum, the two access levels run through two executor contracts, which carry over the short executor and long executor setup from Aave Governance v2. A proposal that bundles payloads of different levels is held to the highest level among them (source: Aave DAO, Governance v3 overview).
A proposal passes only if it clears both tests for its access level. Take a Level 1 vote that closes with 400,000 AAVE voting YES and 300,000 voting NO. The YES total clears the 320,000 threshold and beats NO by 100,000, which is more than the 80,000 margin, so the proposal succeeds. If the same vote closes at 350,000 YES and 290,000 NO, the YES total still clears the threshold, but the 60,000 margin falls short of 80,000 and the proposal fails. A Level 2 vote with 1,500,000 YES and 500,000 NO also fails, because its lead of 1,000,000 is below the 1,040,000 margin that level requires.
Those figures are settings stored in the governance contracts, so a later proposal can change them. The split between proposal power and voting power matters here too. An address that has delegated away its proposal power cannot open a Level 1 AIP, even if it still votes with a large balance, while the delegate that received the proposal power can.
Timelocks, executors, and Guardians
After a proposal passes, its payloads wait in a timelock on each Execution Network before anything changes, and only then can an executor contract apply them. That delay gives users and Guardians a public window to react before a new market setting goes live on the protocol.
The Voting Machine returns the final YES and NO counts to Ethereum through a.DI, where the Governance contract checks them against the thresholds for the proposal's access level. A proposal that passes is forwarded to the PayloadsController on each Execution Network. Its payloads queue there behind a timelock of either one day or 7 days, depending on the type of proposal. Once the wait ends, any address can execute the payload, which the PayloadsController then passes to the right executor contract (source: Aave, Governance).
Aave Community Guardians are multi-signature wallets with limited emergency powers. The Protocol Emergency Guardian holds the EMERGENCY_ADMIN role on Aave markets and acts as the fallback for cross-chain messaging when that system runs in emergency mode. The Governance Emergency Guardian protects against a governance takeover through its power to veto an onchain payload that its signers judge to be malicious (source: Aave, Governance).
That veto is meant for takeover attempts and harmful code, so a disagreement over an ordinary risk setting goes back through votes, delegation, and competing AIPs. In the contracts, a Guardian can cancel a payload only while it has neither been executed nor expired (source: Aave DAO, Governance v3 overview).
You can work out the shortest possible timeline for a Level 1 change from these pieces. The AIP waits through its 1-day cooldown, the vote runs for 3 days, and the payload then sits in a timelock of at least one day. A market change therefore cannot go live sooner than five days after the AIP is created. A vote you see opening today has already been public for at least a day, and a passed vote still leaves you time to adjust a position before the new setting applies.
Trading AAVE beside governance participation
Holding AAVE for votes and trading AAVE for its price are separate decisions with separate tools. Governance power comes from token balances on Ethereum mainnet, while a trade on an exchange changes only your exchange balance, so a price move never speeds up, delays, or reverses a proposal.
If you want another way to trade the AAVE token itself, apart from holding it for proposal or voting power, you can use the AAVE markets on BloFin. BloFin lists AAVE/USDT Spot for buying and selling the token. It also lists the AAVEUSDT Perpetual, a USDT-margined contract that tracks the AAVE price without delivering the token. A spot purchase puts AAVE in your BloFin account, while a perpetual position gives you price exposure only, which is the core difference between spot and perpetual futures. Neither one creates an AIP, casts a Governance v3 vote, or changes a timelock queue.
Suppose you hold enough stkAAVE to matter in a Level 1 vote to list a new asset, and you later buy more AAVE on AAVE/USDT Spot. The vote already counted your stkAAVE through its snapshot of Ethereum balances, so the new tokens in your exchange account add nothing to it. Tokens held on an exchange still form part of the AAVE circulating supply. They only count toward a future proposal once you withdraw them to an Ethereum address before that proposal's snapshot block.
A common mistake is to read a rising AAVEUSDT Perpetual price as a sign that a queued AIP has already changed market caps. The perpetual price reflects trading on the exchange, while the AIP still sits in the timelock on its Execution Network. The protocol itself stays unchanged until an address executes the payload after the wait.
While a Snapshot TEMP CHECK is still open, you might want price exposure to AAVE without waiting for the proposal to take shape. A spot position gives you that exposure today, but it does not help you open the AIP later. That still takes enough proposal power on Ethereum, a registered payload, and an onchain submission.
Trading fees on AAVE/USDT Spot and the AAVEUSDT Perpetual depend on your account tier, and you can check the current maker and taker rates for both markets on the BloFin fee schedule before you size a trade.
What successful proposals usually change
Most successful Aave proposals adjust how the lending markets run: which assets are listed, how high supply and borrow caps sit, how interest rates respond to demand, and which networks host a deployment. A smaller group of proposals deals with the treasury or with the governance system itself.
Typical payloads list or freeze reserves, raise or lower caps, adjust interest rate curves, assign oracle and emission admins, fund incentive programs, and deploy the protocol on new networks. Each change takes effect inside the shared lending pools where suppliers earn interest and borrowers post collateral. That is why a cap change can decide whether your next deposit or loan goes through at all.
Aave V4 shows this in practice. It went live on Ethereum mainnet on March 30, 2026 with three Liquidity Hubs and deliberately conservative supply and borrow caps, chosen as a security-first starting point. The DAO intends to lift those caps, open new Spokes, and extend V4 to other networks once live production data supports each step. Every one of those moves is discussed on the governance forum and then put to a vote (source: Aave Labs, Aave V4 is Live on Ethereum).
Some proposals direct treasury funds, for example into programs that buy AAVE on the open market. Those buyback and Aavenomics decisions pass through the same AIP votes as a cap change. Governance can also rewrite its own rules, because Level 2 proposals can change voting configurations, Guardian roles, and executor permissions. That power over its own design is the reason Level 2 carries the longer vote and the higher thresholds.
For you as a holder, each of these decisions calls for a different tool. Hold or delegate AAVE, stkAAVE, or aAAVE on Ethereum when you want a say in proposals, and vote or pass your vote to a delegate while an AIP is active. Watch the timelock queue when you need to know the moment a market setting will actually change. Trade the token on an exchange when your question is about price, because these are different decisions that happen to share one ticker.
Looking to trade AAVE tokens on BloFin? To get started, you'll need to first create a BloFin account, fund your account with cryptocurrency, then open the AAVE/USDT Spot trading page or the AAVEUSDT Perpetual page.
Frequently asked questions
What is the cancellation fee on an Aave governance proposal?
Creating an AIP requires a small cancellation fee, paid in ETH as part of the creation transaction. The fee covers the cost of canceling a proposal and deters spam attacks funded with flash loans, which are loans borrowed and repaid inside a single transaction. Once the proposal reaches a completed state, any address can trigger the refund of that fee to the proposal creator. If the proposal is canceled, the Aave DAO keeps the fee to cover its costs (source: Aave DAO, Governance v3 overview).
How many Guardian signers must approve an emergency action?
Four of the seven signers on the Protocol Emergency Guardian's multi-signature wallet have to approve before it can act. On the Governance Emergency Guardian, five of nine signers must agree, and the community elects all nine. They come from projects across DeFi, including Zapper, Paraswap, Balancer, Lido, and the security provider Certora. Spreading each emergency power across several independent signers means that no single person can use it alone (source: Aave, Governance).
Who triggers each step of an Aave proposal after it is created?
Almost every step after creation is permissionless, so the Aave Robot, an automation mechanism, or any other address can carry it out. That includes activating the vote once the cooldown ends, settling the Ethereum block data on the Voting Network, closing the vote when time runs out, and executing payloads after the timelock. A payload that needs funds such as ETH can draw them from its executor contract if they were sent there in advance, or from whoever calls the execution function (source: Aave DAO, Governance v3 overview).
How do smart contract wallets vote on Aave proposals?
A smart contract wallet, such as a multisig, cannot sign the messages that storage-proof voting relies on, and it may sit at a different address on each network. To solve that, any Ethereum address can name one representative address for each Voting Network through the governance contract. The representative then votes on that network using the balances and delegations the original address holds on Ethereum. A single address can act as the representative for several others (source: Aave, Governance).
Are Aave delegates paid for voting?
Some Aave delegates are compensated for their governance work through the Orbit program. A delegate is anyone entrusted with voting power, either by other holders or through self-delegation, who then votes on proposals for the people who delegated. Delegators keep holding their AAVE, stkAAVE, or aAAVE and hand over only the vote. That gives their interests a voice in governance without requiring them to take part in every single proposal themselves (source: Aave, Governance).
Can one Aave proposal change markets on several networks?
A single proposal can carry payloads for several networks at once. Each payload is deployed on its target network and registered in that network's PayloadsController, which returns a sequential ID that counts up from one. The proposer lists those IDs and their networks when creating the proposal on Ethereum. One vote can therefore list an asset on Avalanche and adjust a market on Ethereum together. Registering a payload is permissionless and creates no obligation to propose it (source: Aave DAO, Governance v3 overview).
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include Aave's governance documentation, the aave-dao Aave Governance v3 contracts and overview on GitHub, Aave Labs' V4 launch post, Snapshot's documentation, and ethereum.org's DAO primer. All facts independently verified against cited documentation current as of October 2026.
This article is for informational and educational purposes only. It is not financial, investment, trading, or legal advice. Cryptocurrency can lose value. Borrowing on Aave can lead to liquidation if the health factor drops below 1. Spot AAVE/USDT buys the token. An AAVEUSDT Perpetual is a contract on the price. Do your own research. Consider your circumstances before using any protocol or trading any asset.