AaveAave: Collateral, borrowing capacity and withdrawals
Aave connects crypto suppliers and borrowers through smart contracts, with collateral backing ordinary loans and available liquidity limiting withdrawals. Supplying assets creates an interest-bearing position; borrowing creates a separate debt that accrues interest. Collateral eligibility, asset prices and market parameters determine borrowing capacity. Repayment reduces that debt, while withdrawing collateral reduces the assets supporting it. The account balance, debt record and health factor show different parts of this relationship, so a successful transaction needs more context than a wallet confirmation.
Updated -Contents
Repaying debt can release collateral capacity, while withdrawing supplied tokens also requires enough available liquidity in the relevant reserve.
Available collateral and a blocked borrow
An account with eligible collateral can borrow a supported asset when its borrowing capacity, reserve liquidity and market restrictions permit the amount. Merely supplying tokens does not establish that capacity. A supplied asset may lack collateral eligibility, or the account may have its collateral setting disabled.
When disabled collateral causes the restriction, enabling an eligible supply can make it count toward borrowing capacity. That change requires the account to satisfy the applicable collateral rules. If the asset cannot support borrowing in that market, repeatedly submitting the borrow request changes nothing. Leaving the position as a supply preserves its lending function without creating debt.
Supply income, ordinary loans and temporary liquidity
Supplying, borrowing and flash borrowing create different obligations, even though each uses protocol liquidity. Their differences determine whether collateral must remain committed after a transaction.
Supplying without taking a loan
Suppliers contribute assets that borrowers can access under the market rules. The supply earns interest at a changing rate, and supplying alone creates no borrowing obligation. In V3, aTokens represent supplied assets and accrued supply interest. Their balances track the lending position, while borrowers can draw from the underlying liquidity held in the protocol contracts.
Borrowing against a continuing position
An ordinary borrower receives tokens and retains a debt after the transaction completes. Collateral remains exposed to price movements while supporting that debt. This permits access to another asset without first selling the supplied collateral, but interest and liquidation exposure continue on any debt that remains after repayment or another debt-reducing event.
Flash borrowing within a transaction
A collateral-free flash loan requires repayment, including the applicable premium, within the same transaction. Failure to satisfy repayment causes the transaction to revert. V3 also supports a flash-loan method that can open authorized collateral-backed debt instead of repaying selected assets immediately. That option still requires sufficient collateral in the account taking on the debt, plus credit delegation if another account borrows against it; it does not create unrestricted credit.
Wallet access and spending permission
Connecting a wallet lets an interface identify the account; transferring tokens requires the authorization that the particular operation uses. For a supply or repayment that transfers underlying ERC-20 tokens to the V3 Pool, the contract needs sufficient spending allowance. A supported permit can provide authorization through a signature; other cases use an approval transaction. The allowance concerns a particular token and spender. Neither connection nor approval completes a supply or repayment, and changing networks does not move an existing position.
How much can an account borrow?
Borrowing capacity depends on eligible collateral value and its loan-to-value settings, less existing debt, subject to liquidity, caps and borrowing permissions.
Loan-to-value, usually shortened to LTV, governs how much new borrowing the collateral supports. The liquidation threshold serves a different purpose: it helps determine when an existing position becomes eligible for liquidation. Treating these settings as interchangeable hides the distinction between opening a loan and maintaining it.
Asset eligibility matters alongside value. A large supply cannot support a requested borrow if the relevant collateral or borrowing restriction prevents that combination. Parameters can also differ between markets and operating modes. The displayed maximum therefore describes capacity under the applicable state, rather than a permanent amount that the account can always borrow.
Health factor and the risks it does not measure
The health factor compares debt with collateral value after applying liquidation thresholds. It describes the collateral backing an account's borrowing at the prices and parameters that the protocol uses.
For a V3 account with debt, health factor equals total collateral value multiplied by the weighted average liquidation threshold, divided by total borrowing value. A value below 1 makes the position eligible for liquidation. Liquidators repay debt and receive collateral under the applicable liquidation terms.
Prices can change that ratio without any new transaction from the borrower. Accruing debt can also reduce it. Additional eligible collateral or partial repayment can improve the ratio, although subsequent price movements still affect the position.
Health factor does not measure every source of loss. Software vulnerabilities, incorrect oracle valuations and failures affecting a token's backing can harm a position even when its displayed collateral ratio appears comfortable. Network congestion can also delay a needed transaction. These risks affect different parts of the lending mechanism, so a single account metric cannot summarize them.
Interest follows borrowing demand
Borrowing and supply rates respond to reserve conditions, so a rate shown before a transaction does not fix the cost or income over the position's lifetime.
In V3's variable-rate model, utilization influences the borrowing rate through a curve with different slopes below and above a configured usage point. Higher borrowing demand relative to available supply can therefore increase costs sharply. Governance controls the curve's parameters, which differ by reserve.
Supply income and borrowing costs accrue against their respective balances. Comparing their percentages alone misses differences in principal size and asset value. A position can earn supply interest while its borrowing expense exceeds that income. Network transaction fees add separate costs when the account supplies, borrows, repays or withdraws.
Why can a withdrawal fail despite a positive balance?
A withdrawal can fail because the reserve lacks enough available tokens or because removing collateral would violate the account's borrowing constraints.
Collateral that still supports debt
A supply balance describes what the account holds in the protocol. It does not establish how much collateral the account can remove while preserving its debt position. Repayment or additional eligible collateral can increase the amount available for withdrawal under the account's health requirements.
Liquidity that borrowers currently use
The reserve must also hold enough unborrowed liquidity to deliver the requested underlying tokens. Repaying an account's debt does not necessarily replenish the different asset that the account wants to withdraw. Likewise, a high supply rate does not establish immediate withdrawal availability.
These restrictions require different remedies. Improving account health addresses collateral pressure; it does not manufacture missing reserve liquidity. Full repayment removes the account's debt requirement, but the withdrawal still depends on liquidity and the market's operational state.
A partial repayment with a verifiable debt reduction
Consider a hypothetical V3 account whose owner wants to reduce borrowing before deciding whether to withdraw collateral. Assume its debt at execution is 823 units of the borrowed token, it holds 123 units for repayment and the relevant operations remain available. Assume the account has enough network fee tokens but has not approved the Pool to spend the repayment token. Its interface cannot use a permit signature for this repayment.
The limited first action is an approval for the intended 123 units, using the correct token and Pool contract. This supplies the missing spending authorization without granting an unlimited allowance. If authorization remains unavailable, the repayment cannot proceed through that method. The owner leaves the collateral in place rather than withdrawing it to work around the problem.
After the approval succeeds, the owner submits the repayment. Assuming no other debt-changing action occurs, the arithmetic at execution is 823 minus 123, leaving 700 units of debt. Later interest accrual increases that remaining balance. The approval itself would have left the debt unchanged.
The owner checks that the repayment transaction succeeded and that the account's debt fell to 700 units at execution. With collateral prices and other inputs unchanged, the lower debt also improves health factor. The owner stops after the partial repayment and retains the collateral; withdrawal remains a separate choice with separate constraints. This preserves that choice, although the completed repayment still spends tokens and incurs transaction costs.
Market versions and collateral combinations
The same collateral name does not imply identical borrowing rules across every deployment. Version, market configuration and the account's selected mode determine the usable combinations.
V3 efficiency and isolation settings
Efficiency Mode applies category-specific collateral parameters and borrowing permissions. It can increase borrowing capacity for eligible combinations, while restricting which assets the account may borrow. The category's actual configuration matters, including how it treats collateral outside its selected set.
Isolation Mode addresses a different constraint. An isolated collateral asset supports only permitted borrowing assets and a configured debt ceiling. The account cannot combine it freely with other enabled collateral. Supplying another token and enabling that token as collateral are therefore distinct actions.
V4 liquidity and collateral pricing
V4 uses Liquidity Hubs and Spokes instead of V3's market-per-pool design. A Hub manages shared liquidity and accounting; its Spokes implement particular supply and borrowing rules. Limits still govern how much liquidity each Spoke can access.
V4 also includes a user risk premium that relates borrowing cost to collateral quality. This makes the collateral mix relevant to pricing as well as borrowing capacity. These architectural differences do not establish that every feature or asset exists in every deployment.
Repayment, delegated credit and the remaining obligation
Repayment reduces the debt balance, while withdrawal returns supplied assets. Neither operation automatically substitutes for the other, and clearing one borrowed asset leaves any other debt outstanding.
Credit delegation adds a separate authorization relationship. In V3, a collateral provider can authorize another account to borrow against its position. The delegate receives borrowing access, while the debt rests with the collateral provider's account. The protocol still enforces collateral constraints; the parties' agreement governs their repayment relationship.
Revoking unused delegation limits future borrowing through that permission. It does not erase debt that already exists. Closing the credit exposure requires the relevant debt balances to reach zero, including accrued interest. Returning collateral to the wallet then requires a successful withdrawal of the underlying assets. That distinction also applies when another account repays on the debtor's behalf; this repayment does not require credit delegation.
Helpful answers about Aave
Does holding AAVE give someone borrowing capacity?
Holding AAVE in a wallet does not by itself create borrowing capacity. AAVE is the protocol's governance token; a borrowing position requires eligible collateral or an authorized credit delegation arrangement. Using the token as collateral depends on the selected market's support and configuration.
Can another wallet repay my V3 debt?
Another wallet can repay V3 debt on behalf of the account that owes it. The payer must provide the appropriate repayment asset and spending authorization. The repayment reduces the debtor's obligation without transferring that account's collateral ownership to the payer.
What happens to a loan after I disconnect my wallet?
Disconnecting a wallet leaves the loan and its collateral in the protocol. Interest accrual and liquidation conditions continue because the smart contracts maintain the position independently of the browser connection. Closing an interface or removing its wallet connection does not repay debt.
Are aTokens transferable while they support borrowing?
V3 aTokens support transfers, but collateral-related transfers must satisfy the account's health requirements. Moving them can remove collateral from the sending account. A transfer that would leave its borrowing position below the required health threshold fails; the ordinary token transfer feature does not override collateral checks.
Which token does a direct repayment require?
A direct repayment uses the underlying asset that the account borrowed. Holding an unrelated token does not automatically settle the obligation. V3 also supports repayment using the corresponding aTokens for that reserve; a swap-based repayment involves additional operations and their own availability and execution conditions.