Aave (AAVE)

Overview

Aave operates through smart contracts deployed on supported public blockchains. Suppliers deposit approved assets into a market and receive an on-chain representation of their position. Borrowers provide eligible collateral and take loans subject to loan-to-value, liquidation-threshold, interest-rate, and supply-cap rules.

Borrowing is generally overcollateralized. If the value of collateral falls or the borrowed position grows beyond the permitted threshold, third parties can liquidate part of the position according to protocol rules. Price oracles are therefore critical infrastructure. Incorrect, delayed, or manipulated pricing can affect borrowing power and liquidation.

Interest rates respond to market utilization and governance-configured models. A high displayed rate can change quickly and can reflect limited liquidity or elevated demand. Supplying an asset does not remove the underlying token’s price, issuer, bridge, or depeg risk.

AAVE token holders participate in governance processes that can change assets, risk parameters, deployments, and protocol components. The token and related safety mechanisms should be distinguished from ordinary deposits and loans.

Applications integrating Aave should verify the official deployment, market, asset address, oracle configuration, transaction receipt, and resulting account health. They should not infer that an identically named asset on another chain is supported. Aave automates lending and borrowing without a traditional intermediary, but users still depend on contract correctness, governance, liquidity, oracle quality, and their own collateral management.

Risk parameters can differ across chains and market versions. An asset enabled as collateral in one deployment may be supply-only or unsupported in another. Integrations should retain market address and parameter version with each position. This prevents dashboards from combining balances whose borrowing power, liquidation threshold, or withdrawal liquidity are not actually equivalent.

Aave (AAVE), GHO, and Venus (XVS) may appear in the same workflow. Every component connected to Aave (AAVE) should therefore be validated independently so a related asset or mechanism is not credited as the intended token.