Aave lets you supply crypto and borrow against eligible collateral

Borrowing and the resulting account balance

A successful borrow transfers the requested asset to the recipient and records an interest-bearing obligation against the collateral account. The account therefore has two relevant changes: accessible borrowed tokens and outstanding debt. Interest starts accruing when borrowing occurs. Available borrowing capacity falls, and the health factor reflects the additional obligation relative to eligible collateral. The transaction amount alone does not describe the resulting position.

In V3, the Pool contract exposes account data that includes collateral value, debt value, remaining borrowing capacity, and health factor. These values describe the account within that pool. A wallet balance only shows tokens held by the wallet; it does not replace the protocol account record. Reading both helps distinguish borrowed funds from an obligation that remains outstanding.

Supply, borrowing, and delegated access

Supplying transfers assets into protocol contracts, where borrowers can access available liquidity under the applicable rules. In V3, suppliers receive aTokens that represent their supplied balance and accrued interest. Enabling eligible supplies as collateral adds borrowing capacity. Leaving assets outside collateral use preserves a supply position without making those assets support borrowing.

Open full-size image

Credit delegation grants a specific borrowing allowance. The delegate receives borrowed assets while debt attaches to the delegator's account. Separate agreements govern repayment arrangements between them, and protocol collateral checks still apply. Flash borrowing instead depends on transaction-level settlement.

Market and version compatibility

The selected deployment determines the account that an interface reads, the assets it accepts, and the operations it can execute. Wallet connectivity alone does not establish asset eligibility. In V3, each market has its own Pool contract and reserve configuration. A reserve is the protocol's accounting and configuration for a particular asset. Supply availability, borrowing permissions, and collateral eligibility are separate settings. For an ordinary supplied reserve, available liquidity and any remaining borrow cap can further limit borrowing below the account's collateral-based capacity.

V4 uses a Hub and Spoke architecture. Hubs hold shared liquidity and accounting, while Spokes manage particular lending configurations and user positions. A V4 position belongs to its Spoke, so V3 account mechanics should not be assumed to apply unchanged. An interface must support the deployment holding the position. If that support is absent, another compatible interface or direct contract access is necessary.

Collateral eligibility and borrowing capacity

Supply status and collateral status

A supplied asset contributes to borrowing only when the market permits collateral use and the account enables it. Collateral status therefore matters separately from the supplied balance. Disabling collateral removes its contribution to the account's backing, even though the supply position remains. Existing debt can prevent that change when the remaining collateral would fail protocol requirements.

Loan-to-value and liquidation threshold

Loan-to-value, or LTV, limits the borrowing capacity that eligible collateral provides. The liquidation threshold determines how that collateral contributes to liquidation eligibility. These parameters serve different purposes. A balance can support existing debt under its liquidation threshold while providing little or no capacity for additional borrowing. Governance can change collateral parameters, so historical settings do not establish the terms of a later transaction.

How does the health factor change?

The health factor changes when eligible collateral values, debt values, accrued interest, or applicable liquidation parameters change. It expresses collateral backing relative to debt.

Open full-size image

In V3, health factor equals total collateral value multiplied by the weighted average liquidation threshold, divided by total debt value. The calculation uses a common valuation basis for collateral and debt.

A falling collateral price reduces the numerator. A rising price for a borrowed asset increases the debt valuation. Interest also grows the obligation without requiring another borrow transaction.

A health factor below 1 makes a position eligible for liquidation. A liquidator repays eligible debt and receives collateral with the applicable liquidation bonus. The amount that liquidation can remove depends on the deployed version and position conditions.

There is no universal health factor that makes every position equally resilient. Asset volatility and the relationship between collateral and debt prices affect how quickly the margin changes. A value above the threshold describes current collateralization, rather than protection against future price movements.

Interest costs and supply returns

For reserves using V3's standard interest rate strategy, variable borrowing rates respond to reserve utilization and configured rate parameters. This model has separate slopes below and above its optimal utilization point. Supply returns reflect borrower interest after the reserve factor, which allocates a portion to the protocol. Network transaction fees add a separate cost when executing actions. A displayed annualized rate can change during an open position; it does not fix the total interest payable.

Specialized borrowing configurations

Efficiency Mode

Efficiency Mode, or E-mode, applies category-specific collateral parameters and borrowing permissions in V3. An eligible configuration can provide greater borrowing capacity. Compatibility follows the category's actual collateral and debt permissions, rather than a general resemblance between assets. Entering, leaving, or changing a category can alter the account's available capacity.

Isolation and siloed borrowing

In V3 deployments that retain and enable these features, reserve Isolation Mode limits borrowing against designated collateral to approved assets and a debt ceiling. It also restricts combining that collateral with other enabled collateral. Siloed borrowing addresses the debt side: borrowing a siloed asset prevents other active borrow assets in the same V3 pool. Where enabled, these restrictions can block an otherwise collateralized borrowing request. V3.7 removes both reserve-level modes, so their applicability depends on the deployed version and configuration.

Flash borrowing

V3 flash loans support contract operations that settle within one transaction. The simple flash-loan method requires repayment with the applicable fee. The broader method can instead open eligible variable debt against sufficient collateral, with credit delegation required when borrowing on another account's behalf. Failure to meet settlement conditions reverts the transaction. Flash borrowing therefore has different requirements from leaving an ordinary loan outstanding.

Wallet permissions and contract access

Token approval authorizes a contract to spend an asset within the allowance granted by the wallet. It does not itself supply tokens or repay debt. Depending on token and interface support, approval can use an onchain transaction or a permit signature. The spending contract and amount define the permission. Credit delegation grants borrowing authority through a separate mechanism, so it carries a different consequence from approving a token transfer.

Risks outside the health calculation

Smart contract defects, incorrect oracle valuations, and network failures can affect a position even when its displayed health factor appears comfortable. Oracle prices feed the collateral and debt calculations. If those valuations fail to represent the relevant assets correctly, the resulting account metrics can misrepresent economic exposure. A health reading does not independently assess software security or token backing.

Bridged assets also depend on the systems that maintain their backing across networks. Problems with that backing can affect market value and liquidity. Congestion can delay an adjustment transaction during a price move, while collateral illiquidity can complicate liquidation. These risks attach to the actual asset and deployment; using the same protocol name across networks does not remove them.

Why can a withdrawal be unavailable?

Insufficient unborrowed liquidity

A withdrawal can be unavailable because the reserve lacks sufficient unborrowed liquidity or because removing collateral would violate account requirements. These are separate constraints. Withdrawing supplied assets requires enough available unborrowed liquidity in the relevant pool. A supplied balance records a claim on assets, while the available liquidity determines how much the pool can currently transfer.

Collateral supporting outstanding debt

Collateral withdrawal reduces the backing available for remaining debt. Partial repayment or additional eligible collateral can change the permitted withdrawal amount. Neither action automatically solves a reserve liquidity shortage. Conversely, plentiful liquidity does not permit removing collateral that the debt still requires. The failed condition determines whether changing the account can make the withdrawal possible.

Repayment, adjustment, and exit

Repayment reduces the outstanding obligation using the borrowed asset, including interest that has accrued. Partial repayment leaves a continuing debt position. Full repayment clears that obligation, while supplied collateral remains in the protocol until withdrawal. A direct repayment and a withdrawal therefore have different completion evidence: the former changes debt, and the latter returns supplied assets.

Some V3 operations can repay debt using aTokens for the same underlying asset in the same pool. Repayment through a different asset requires a compatible conversion mechanism and its additional execution conditions. Debt cancellation should not be inferred from a token approval or an unrelated wallet transfer. A closed borrowing position has no remaining debt; a complete withdrawal also requires the relevant supplied balance to leave the protocol. Available liquidity can still limit that final step after repayment.

Open full-size image