Aave is a liquidity protocol for lending, borrowing and yield

Aave is a shared pool of crypto supplied by depositors and borrowed by users who lock higher-value assets as collateral. Its smart contracts match pooled liquidity with overcollateralized demand, credit supplier balances with variable interest, and track each borrow on a public blockchain. Users keep control of their wallets, choose a network and market, then approve transactions rather than opening a conventional account. The protocol supports ordinary supplies and loans as well as developer tools such as atomic flash liquidity.

In short: It is a decentralized liquidity protocol where users supply crypto to earn interest or borrow against collateral.

From wallet connection to an interest-bearing position

The Aave supply workflow moves from wallet connection to an interest-bearing position in five practical moves. First, hold a supported asset and the network's gas token in MetaMask, a Ledger-connected wallet, or another compatible EVM wallet. Next, choose the exact chain and market, connect the wallet, select the asset, and enter an amount below the displayed wallet balance and reserve cap.

An ERC-20 asset normally requires an allowance before the Pool contract can move it. The standard route therefore uses two on-chain transactions - one approval and one supply - while an EIP-2612 permit replaces the approval transaction with one signed message when the token and interface support it. After confirmation, the dashboard shows the supplied position and its accruing balance.

To exit, choose Withdraw and return the same underlying asset in one transaction when unborrowed liquidity is available. If the position backs debt, the proposed withdrawal must leave enough collateral for the health-factor rules; otherwise the transaction does not execute. This sequence makes the selected market, not the wallet brand, the first consequential decision.

Choose the chain and market before moving any tokens

Network and market selection in Aave determine where the position exists, which assets it reaches, and which contract version accounts for it. Ethereum mainnet uses chain ID 1, Base uses 8453, and Arbitrum One uses 42161; the same-looking address on those networks points to separate balances and separate protocol deployments.

V3 runs independent pools on Ethereum, Base, Arbitrum, Optimism, Polygon, Avalanche, and other approved networks. V4 is active on Ethereum and Avalanche and organizes each deployment around Liquidity Hubs and user-facing Spokes. A V3 deposit does not automatically appear inside V4, and liquidity on one chain does not fund a withdrawal on another. Match the network displayed in the wallet, interface, and token balance before authorizing any action.

Five checks before choosing supply, collateral or debt

The position checklist tests five concrete conditions before supply, collateral, or debt is enabled. An EVM address occupies 20 bytes and is normally shown as 42 characters including the 0x prefix, yet address similarity does not merge networks or markets.

• Network balance: The asset and its gas token must both exist on the selected chain.
• Reserve status: The market must be active, unfrozen, and below its configured supply or borrow cap.
• Position role: Decide whether the supply earns interest only or also becomes collateral.
• Borrow buffer: A collateralized position should remain comfortably above a health factor of 1 after the transaction.
• Exit conditions: Confirm that unborrowed liquidity exists and that collateral is not locked behind unpaid debt.

Supplying without collateral enabled avoids liquidation exposure from that position, although the token's market value still moves. Enabling collateral unlocks borrowing power and adds a price-sensitive constraint. Isolation Mode allows an isolated asset to serve as the sole collateral while limiting borrowing to governance-approved stablecoins, so its market icon changes the decision materially.

Utilization turns borrowing demand into supplier yield

The interest-rate model in Aave converts reserve utilization - the share of supplied assets already borrowed - into variable borrowing cost and supplier yield. A low utilization level leaves funds idle and pulls rates down; utilization approaching the configured optimal point raises rates, while the steeper segment beyond that point encourages repayment and fresh supply.

The displayed supply rate comes from the variable borrow rate multiplied by utilization, then reduced by the reserve factor directed to the protocol. External incentives, where present, are shown separately. One basis point equals 0.01%, and 10,000 basis points equal 100%; these fixed units make fee and rate parameters comparable even though the annual percentage changes with demand.

Interest starts accruing when the supply transaction settles. V3 rate calculations use a 365-day year, or 31,536,000 seconds, while balances advance through indexes rather than individual daily payouts. A low displayed rate paired with deep available liquidity may serve an exit-focused supplier better than a thin reserve paying a momentarily higher rate.

Supply positions, collateralized borrowing and flash liquidity serve different jobs

Three Aave use cases share the same liquidity infrastructure but create very different positions: supplying for yield, borrowing against collateral, and atomic flash liquidity for contract workflows. Supply leaves the user exposed to the deposited asset while interest accumulates. Borrowing releases another supported token without selling the collateral, although interest increases debt and price movements alter the collateral buffer.

GHO adds a protocol-native stablecoin route: approved collateral supports GHO borrowing, and the borrowing rate is set through governance rather than a supplier reserve's utilization curve. Flash loans serve developers performing arbitrage, collateral changes, or refinancing within one atomic transaction. If the borrowed amount plus premium is not returned before that transaction ends, every step reverts.

The V3 Ethereum flash-loan configuration charges a total premium of 5 basis points, split into 4 basis points for the protocol and 1 basis point for suppliers; approved flash-borrower routes receive a 0-premium waiver. That parameter is governance-controlled, so the transaction preview for the selected route determines the final cost.

aTokens make a supplied balance portable and interest-bearing

V3 aTokens turn each supplied reserve into a transferable, interest-bearing ERC-20 balance. Supplying USDC produces aUSDC, while supplying WETH produces aWETH; the aToken represents the holder's claim and remains redeemable against its underlying asset subject to available liquidity.

At minting, accounting begins at a 1:1 underlying-unit relationship, then the visible aToken balance grows through the liquidity index. The token copies the underlying asset's precision, so aUSDC uses 6 decimals and aWETH uses 18. EIP-2612 permit support adds signed approvals, and standard ERC-20 transfers allow many V3 aTokens to move between addresses while carrying the claim.

V4 uses share-based Hub accounting and exposes supply positions through ERC-4626 Tokenization Spokes, so a V4 share should not be assumed to behave exactly like a rebasing V3 aToken. That difference matters to wallets, accounting tools, and integrations even when both interfaces display an interest-bearing supply.

Health factor converts collateral prices into a liquidation boundary

The V3 health factor converts collateral values, asset-specific liquidation thresholds, and total debt into one boundary. Values above 1 indicate enough weighted collateral; falling below 1 makes the position eligible for permissionless liquidation.

When the health factor is above 0.95 and both collateral and debt are worth at least $2,000, up to 50% of total debt may be liquidated; at 0.95 or lower, or when either side is below $2,000, up to 100% may be liquidated. A partial liquidation must leave at least $1,000 of collateral and $1,000 of debt, or the position is cleared completely.

Configured Chainlink feeds and oracle adapters update the collateral and debt values, while interest increases the borrowed amount between user actions. The main financial risk is therefore a moving ratio rather than a scheduled maturity. Withdrawal availability adds another constraint because suppliers redeem only liquidity that is not currently borrowed. Contract and oracle risk remain part of the security model, and governance changes caps, thresholds, bonuses, and rate curves that govern positions.

V3 pools and V4 Hubs organize liquidity differently

The Aave architecture has two active designs: V3 isolates liquidity by pool, while V4 routes activity through Hubs and Spokes. In V3, a Pool stores reserve state, mints aTokens, issues variable debt tokens, and enforces a configuration with space for up to 128 initialized reserves. Each network or Ethereum market maintains its own balances, utilization, caps, and oracle settings.

V3 fixed-point accounting uses 18-digit wad precision for token-scale values and 27-digit ray precision for rates and indexes; the conversion ratio between them is 10^9. These indexes let the contracts calculate an updated balance from shared state instead of sending an interest payment to every supplier.

V4 separates the accounting and liquidity Hub from Spokes that define collateral sets, borrowable assets, premiums, and liquidation rules. Ethereum V4 activated with 3 Hubs and 5 initial assets - WETH, WBTC, USDC, USDT, and GHO - so the version began with a deliberately narrower surface than the broad V3 catalog. The Hub enforces how much each Spoke may add or draw, concentrating liquidity without giving every borrowing configuration identical risk terms.

Governance changes parameters without custody of user wallets

Aave Governance changes protocol parameters through AAVE, stkAAVE, and aAAVE voting power rather than through custody of user wallets. Proposals adjust asset listings, supply and borrow caps, interest-rate curves, oracle adapters, and contract implementations, while approved payloads execute on-chain after voting and timelocks.

The documented Short Executor path uses a 1-day delay, a 3-day vote, and a 1-day timelock; the Long Executor uses a 10-day vote and a 7-day timelock for governance-level changes. Delegation lets holders assign voting power without transferring the underlying token. The 2020 migration fixed the conversion at 100 LEND for 1 AAVE and created a 16 million-unit AAVE supply, while the token retains 18 decimal places as an ERC-20 asset.

Governance makes the system adaptable, yet that adaptability means screenshots and remembered parameters age. A position review should focus on the values encoded for its exact reserve and market: loan-to-value, liquidation threshold, cap headroom, available liquidity, and rate curve.

Compound III, Morpho Blue and SparkLend change the decision

Compound III, Morpho Blue, and SparkLend are real lending alternatives whose market structures change what a supplier or borrower accepts. Compound III organizes each Comet market around one borrowable base asset; supplied collateral assets support borrowing but do not earn the base supply rate. That design narrows the choice set.

Morpho Blue defines an isolated market with five parameters: loan token, collateral token, oracle, interest-rate model, and liquidation loan-to-value. Its permissionless market creation shifts more selection work to users and vault curators. SparkLend is based on the V3 codebase and applies its own governance and risk configuration, with close ties to the Spark and Sky ecosystem.

Choose Aave when pooled multi-asset markets, established aToken integrations, and a broad chain footprint match the job. Choose Compound III for a base-asset-centered market, Morpho Blue for immutable isolated-market terms, or SparkLend for its ecosystem-specific liquidity. None removes asset volatility, contract exposure, oracle dependence, or liquidation rules; the meaningful difference is where each protocol concentrates those trade-offs.

Aave: what people ask

Posted: 2026-08-05