Aave (AAVE): How Lending, Health Factor and Liquidation Work
The borrow transaction succeeded. The position can still be close to liquidation. Aave is a non-custodial lending protocol: the user controls the wallet, while protocol contracts account for supplied assets, collateral and debt. A confirmed transaction proves execution, not position health. AAVE is the governance token; it is not the normal gas currency or the receipt for a supplied position.
Use this page to follow an Aave position from supply and collateral selection through borrowing, monitoring, repayment and withdrawal, with the checks that matter before another transaction is signed.
Subject:
Aave
Market mode:
Snapshot Only
Fee asset:
Varies
Timezone:
UTC
This page does not show live lending rates, monitor a connected wallet, recommend collateral, predict liquidation timing or provide a complete AAVE governance or staking guide.
An Aave position is built through several separate transactions. The wallet can show success at every step while the final combination of collateral and debt remains fragile.
An Aave position moves through distinct approvals and transactions; the final protocol state is the completion check.
Choose the deployment before the asset
Start with the host network and the specific Aave market. Ethereum, Arbitrum, Polygon PoS and other deployments do not share one balance sheet: available liquidity, supported assets, caps, collateral permissions and risk parameters can differ. The same ticker on another network can represent a different contract or bridged asset. The wallet also needs that host network's gas currency for approvals, supply, borrowing, repayment and withdrawal.
Supplying transfers an approved asset into the selected Pool contract. ERC-20 assets may require an allowance or supported signed approval first. The protocol records an interest-bearing supply position, commonly represented through an aToken balance. That representation is not AAVE. A supplied asset may be eligible as collateral, but collateral use is a separate status with its own loan-to-value and liquidation-threshold consequences.
Borrowing creates a position that keeps changing
A borrow transaction transfers the selected debt asset to the wallet and begins accruing variable debt. Before signing, check the projected health factor, borrow rate, available liquidity and whether isolation mode, efficiency mode or another deployment rule changes what can be borrowed. The interface maximum is a protocol limit, not a sensible target. A larger buffer gives the position more room to absorb price movement, interest and transaction delay.
Repayment reduces debt after it confirms on the same deployment. Withdrawing supplied assets can be limited by available pool liquidity and by the health factor that would remain after collateral is removed. A pending repayment, bridge transfer or collateral deposit has no protective effect until the relevant transaction succeeds and protocol state changes. Confirm the resulting balances and collateral status on the actual position, not only the wallet receipt.
The transaction succeeded. The position can still be unsafe. Health factor is the protocol's live summary of liquidation protection, not a certificate that a borrow was prudent.
Health factor can move from a wider buffer toward liquidation eligibility; the diagram does not prescribe a universal safe target.
What the ratio represents
Conceptually, Aave divides collateral value adjusted by weighted liquidation thresholds by total borrow value. A higher result means more room before liquidation eligibility. A value below 1 means the position can be liquidated under the active market rules. Loan-to-value determines borrowing capacity at entry; the liquidation threshold marks a different boundary. Treating those two parameters as interchangeable can make a new position appear safer than it is.
Health factor can fall because collateral loses value, the borrowed asset gains value or interest increases the debt. Oracle updates, collateral configuration and the mix of several assets also matter. There is no universal safe number for every position. Volatility, asset correlation, market liquidity, network conditions and the user's ability to respond all change the useful buffer.
What happens after the boundary is crossed
Once a position is eligible, a permissionless liquidator can repay debt and receive collateral under the current close-factor and liquidation-bonus rules. The borrower does not approve that transaction when it occurs. The amount can depend on health factor, position size, assets and protocol configuration, so a simplified example should not be treated as a promise about a particular account.
Repaying debt or adding eligible collateral can improve health factor, but the rescue must confirm first. During a fast move, a user's submitted transaction can remain pending while a liquidator pays a higher priority fee and executes. Automation and alerts can help with monitoring; neither guarantees transaction ordering or protection. Prepare the repayment asset and gas route before the position approaches the boundary.
The rate changed. The debt kept accruing. Aave rates respond to market use, while withdrawal depends on both liquidity and the position left behind.
Utilization changes both sides of the market
Supply and variable borrow rates follow the interest-rate strategy configured for an asset. As a larger share of supplied liquidity is borrowed, the rate can rise to encourage supply and repayment and discourage more borrowing. When utilization falls, rates can fall. The annual percentage shown before a transaction is therefore a current estimate, not a fixed contract rate or guaranteed return.
Borrow interest adds to outstanding debt and can gradually reduce health factor even if token prices appear unchanged. Suppliers earn according to protocol accounting, but the ability to withdraw the underlying asset depends on unborrowed liquidity. If much of a reserve is in use, a full withdrawal may not be immediately available. If the supply is collateral, withdrawal can also fail because removing it would leave the borrow position unhealthy.
A supply position is not a protected deposit
Suppliers remain exposed to the supplied token, the Aave contracts, price feeds, governance changes and the host network. Stablecoins can lose their intended value, and wrapped or bridged assets add issuer, custodian or bridge dependencies. A high rate can reflect scarce liquidity or greater demand rather than improved safety. Compare the exact asset and deployment, then plan how the underlying asset can be withdrawn without weakening another position.
The wallet is connected. The wrong market can still be selected. Several expensive Aave failures begin with an avoidable operational decision rather than an unknown contract defect.
Leave room for the transaction after this one
Borrowing near the interface maximum creates a weak health-factor buffer from the start. It also leaves little room for accrued interest, price movement or a collateral-status change. Keep enough host-network gas to approve a repayment asset, repay debt, add collateral or withdraw later. A wallet that can open the position but cannot fund the next management transaction is not operationally prepared.
Verify the deployment, market version, token contract and asset representation. A bridged token can depend on a bridge or custodian that the native asset does not. Review allowances separately from the supply or repay action; an unlimited approval can remain after the position changes. The interface preview is useful, but the confirmed debt, collateral flag and health factor are the state that matters.
Choose a deliberate health-factor buffer rather than the maximum borrow amount.
Keep gas and the repayment asset available on the same network.
Verify token contracts, collateral status and approval scope.
Check the final protocol position after every material transaction.
Aave and Compound both support overcollateralized on-chain borrowing, but a comparable task can produce different asset roles and risk calculations.
Aave and Compound III organize lending markets differently; compare the exact deployment and task rather than a temporary rate.
Compare the exact market, not the token prices
An Aave deployment can support several supplied and borrowed assets inside a governed market, with asset-specific collateral settings and features such as isolation or efficiency modes where available. Compound III organizes each Comet deployment around one base asset. Users can supply that base asset for interest or borrow it against listed collateral; collateral assets have a different accounting role from the base asset.
Aave summarizes eligible collateral and debt through its health-factor model. Compound III distinguishes borrowing collateral factors from liquidation collateral factors around its base market. Neither structure removes oracle, contract, liquidation, approval or gas risk. Recalculate the position when switching protocols instead of copying a familiar buffer. Supported networks, liquidity and parameters also differ by deployment.
Decision
Aave
Compound III
Market structure
Multi-asset governed deployments
One base asset per Comet deployment
Supply role
Supported reserves can earn and may serve as collateral
Base asset can earn; listed collateral has a separate role
AAVE matters to protocol governance, but a lending user should not confuse token ownership with the supply, debt or gas balances needed to manage a position.
Governance is separate from borrowing
AAVE can carry governance voting power directly or through eligible delegation arrangements under current governance rules. Approved governance actions can change protocol components, deployments and risk parameters. A person can supply or borrow in a supported Aave market without holding AAVE, while an AAVE holder does not automatically have a lending position.
AAVE does not pay ordinary Ethereum, Arbitrum or Polygon PoS gas, does not represent every supplied asset and does not prevent liquidation. Ownership does not guarantee protocol revenue, supply returns or recovery from a failed transaction. Protection and staking arrangements can use specific modules and eligible assets that change over time; verify those separately rather than extending this lending guide into a staking tutorial.
The Next Position Check
Before opening or changing an Aave position, make the next failure path visible. The checklist is short because every item must be confirmed for the exact deployment.
Verify before signing
Confirm the host network, Aave market, token contract and gas balance. Check whether the supplied asset is enabled as collateral, the projected health factor after the action, the scope of any token approval and the available liquidity for the intended borrow or withdrawal. Record the repayment asset and route before debt is opened.
After confirmation, inspect the actual supplied balance, debt, collateral status and health factor. If any value differs from the preview, stop before stacking another transaction on top. A market snapshot for AAVE says nothing about a wallet's collateral quality, current lending rate or liquidation timing. Those conclusions require the live position and deployment data that this reference page does not collect.
Network and Aave market
Asset contract and representation
Gas for opening and managing the position
Collateral status and health-factor buffer
Repayment route, withdrawal liquidity and approval scope
Aave Lending FAQ
Focused answers about supplying, borrowing, health factor, liquidation, deployments and the supporting AAVE token role.
How does Aave lending work?
Aave uses smart-contract markets where users supply supported assets and other users borrow available liquidity against eligible collateral. A supplier receives an interest-bearing position whose rate changes with market utilization. A borrower receives the borrowed token and accrues variable debt. Each deployment has its own assets, liquidity, caps and risk parameters. The user keeps control of the wallet but must pay host-network gas, review approvals and monitor the resulting position. A successful transaction does not guarantee that the collateral buffer is suitable.
How do you borrow from Aave?
Choose the correct network and Aave market, supply an eligible asset, and enable it as collateral when appropriate. Then select a borrowable asset and review available liquidity, the variable rate, loan-to-value, liquidation threshold and projected health factor. Confirm the transaction with enough host-network gas. Debt begins accruing after execution. Keep the repayment asset and gas available on the same deployment, monitor the final health factor, and do not treat the interface maximum as a recommended amount.
What is Aave health factor?
Aave health factor compares collateral value adjusted by weighted liquidation thresholds with total borrow value. A higher result means more room before liquidation eligibility; a value below 1 means the position can be liquidated under current rules. The ratio changes when collateral prices, borrowed-asset prices, accrued interest or position balances change. It is not a universal safety score. Useful buffers differ with asset volatility, correlation, liquidity, network conditions and how quickly the user can confirm a repayment or collateral transaction.
What happens during an Aave liquidation?
When health factor falls below 1, a permissionless liquidator can repay eligible debt and receive collateral under the active close-factor and liquidation-bonus rules. The borrower does not approve the liquidation when it occurs. The amount can depend on health factor, position size, assets and protocol configuration. A pending rescue transaction does not pause eligibility; it must confirm before a competing liquidation. Repaying debt or adding eligible collateral can improve health factor, but neither action protects the account while it remains pending.
Can you lose money supplying assets on Aave?
Yes. A supply position is not a guaranteed bank deposit. The supplied token can lose value or fail, smart contracts and price feeds can fail, governance can change parameters, and wrapped or bridged assets add separate dependencies. Variable supply rates can fall. Withdrawals also depend on unborrowed pool liquidity, and a supplied asset used as collateral may not be removable if withdrawal would weaken an active borrow position. Review the exact asset, deployment and exit path rather than relying on a displayed annual percentage.
Which networks support Aave?
Aave operates through governance-approved deployments on multiple networks, including Ethereum and several scaling or alternative networks. The current list can change, and each deployment has separate contracts, assets, liquidity, parameters and gas requirements. A balance on one Aave deployment does not automatically exist on another. Before supplying or borrowing, verify the network in the wallet, the official market, the token contract and the host-network fee asset. Treat bridging as a separate transaction with additional contract and asset-representation risk.
Aave vs Compound: what is the difference?
Aave can organize several supplied and borrowed assets inside a governed deployment with asset-specific collateral settings. Compound III organizes each Comet market around one base asset that can be supplied for interest or borrowed against listed collateral. Their rate models, collateral accounting, liquidation parameters, supported assets and network deployments are not interchangeable. Compare the exact market and intended debt asset, not token prices or a temporary yield. A risk buffer that looks reasonable in one protocol should be recalculated for the other.
What is the AAVE token used for?
AAVE is the protocol's governance token. Eligible holders or delegates can participate in governance processes that may change protocol components, deployments and risk parameters. That role is separate from everyday lending. AAVE is not the normal gas asset on Aave's host networks, does not represent every supplied position and is not required for every supply or borrow transaction. Holding AAVE does not guarantee lending returns or prevent liquidation. Current staking or protection modules should be researched separately because their eligible assets and risks can change.
Known Limitations
This page does not read a connected wallet, quote live lending rates or monitor a position's health factor.
Market parameters, supported deployments and liquidity can change after editorial review.
Market Data Methodology
The page uses a CoinGecko aggregated AAVE/USD snapshot. No exchange chart is rendered for this entity.
Market Snapshot Source
CoinGecko aggregated market data (AAVE/USD)
Cache
Snapshot cache is approximately 60 seconds.
Failure Handling
Verified cached data is labeled Cached or Delayed. Missing values remain unavailable.
