Aave is where Asset Supply Becomes a Verifiable Position

Aave is a liquidity protocol in which the first supply follows a concrete onchain sequence: choose the correct deployment and market, connect a wallet holding a supported asset, authorize the required token transfer, submit the supply transaction, confirm the recorded position, and later withdraw the underlying asset. The wallet address remains the position owner throughout. Interest begins accruing after the supply settles, while the displayed rate and available capacity come from the selected market rather than from a fixed account contract.

Published 2026-08-06

Key takeaway: A fresh ERC-20 supply commonly requires two onchain transactions: one allowance change and one supply call.

A market mismatch makes a valid supply look missing

An Aave supply position belongs to one wallet address, one blockchain deployment, and one selected V3 market or V4 Hub-and-Spoke route. A market mismatch changes the dashboard view without moving or deleting the underlying position, so the first useful check is whether all three identifiers still match the original transaction.

Chain IDs distinguish networks even when their interfaces and token tickers look similar. Ethereum Mainnet uses chain ID 1, Arbitrum One uses 42161, Base uses 8453, Optimism uses 10, Polygon PoS uses 137, and Avalanche C-Chain uses 43114. USDC held on one of these networks is a separate ERC-20 contract from USDC on another, and selecting the wrong deployment reveals a different wallet balance and protocol state.

On Ethereum, Aave V4 organizes deposits by a Spoke name paired with a Hub name. Aave V3 instead presents each deployment as its own market and pool. Under the V4 workflow, the Spoke records the user-facing position while the connected Hub holds and accounts for liquidity. Record the network, version, asset ticker, and full market label before the first signature; those details provide the shortest route back to the position.

Prepare the wallet, asset, and transaction capacity

First-supply prerequisites consist of the exact wallet account, a supported token on the selected network, and enough native network currency to submit the required transactions. An EVM address is 20 bytes, or 160 bits, and its familiar representation contains 40 hexadecimal digits after the 0x prefix - 42 characters in total. The same address must remain selected when checking or withdrawing the position.

Token precision matters because contracts receive integer base units rather than decimal text. USDC uses 6 decimals, so 1 USDC is encoded as 1,000,000 base units. WETH uses 18 decimals, making one whole WETH equal to 10 ¹⁸ base units. Ether also has 18 decimal places, and 1 wei equals 10 ⁻¹⁸ ETH. A wallet interface performs these conversions, but the displayed amount deserves a final check before signing.

MetaMask and Rabby connect directly to EVM applications, while WalletConnect links other compatible wallet applications. Ethereum, Arbitrum One, Base, and Optimism use ETH for transaction execution; Polygon PoS uses POL, and Avalanche C-Chain uses AVAX. The supplied token and the native transaction token therefore occupy two separate wallet balances. Holding USDC alone does not provide the ETH, POL, or AVAX required to record the supply.

Select the supply market before authorizing the token

The connected topic is covered under Aave liquidations. The supply market determines where the asset goes, which capacity applies, and how the resulting position is accounted for. Aave Pro presents V4 deposit markets by their Spoke-and-Hub pair, while the Aave V3 interface presents supported assets inside the chosen deployment. Remaining capacity of 0 blocks an additional supply even when the connected wallet holds enough tokens.

A standard ERC-20 supply with no existing allowance produces two onchain transactions: an approval followed by the supply call. An existing sufficient allowance reduces the workflow to one onchain supply transaction. When a supported token offers a permit path, a signed message replaces the onchain approval, but the supply itself still requires one settled transaction. Approval alone never creates a supplied position.

ERC-20 allowances are unsigned 256-bit values, whose maximum is 2 ²⁵⁶ −1. An exact-amount approval authorizes the intended transfer, whereas a larger approval leaves unused allowance available for later interactions with the same contract. After authorization, enter an amount no greater than the displayed wallet balance and remaining market capacity, then inspect the wallet request for the correct network, token, amount, and protocol action. Settlement reduces the ordinary wallet balance and records the supplied amount under the connected address.

Confirm the receipt and identify the resulting position

Transaction confirmation proves whether the supply altered protocol state. On EVM networks, receipt status 1 represents successful execution, while status 0 represents a reverted transaction. Approval and supply have separate receipts when both were onchain, so the presence of a successful approval does not establish that the second action settled.

In V3, each aToken unit maps one-to-one to the underlying asset, while the wallet's aToken balance rises through the liquidity index. Examples include aUSDC for supplied USDC and aWETH for supplied WETH. Some wallets do not display these tokens automatically, making the protocol dashboard a clearer position view. V4 uses share-based accounting inside the selected Spoke instead of relying on the V3 aToken presentation, and its dashboard converts those shares into the displayed underlying amount.

The confirmation state should reconcile three observations: the wallet's underlying-token balance fell by the supplied amount, the selected market shows a corresponding position, and the transaction record names the same asset and beneficiary address. A fiat-denominated valuation moves with the asset's market price, so the token-unit balance provides the cleaner supply check. Once those records agree, the wallet no longer needs to stay connected for the position to remain active.

A hypothetical USDC position from supply to partial exit

A worked USDC example shows how wallet balance, supplied balance, and withdrawal amount reconcile. Every changing input in this example is hypothetical: the wallet begins with 1,250 USDC, the intended supply is 1,000 USDC, the later displayed position is 1,012.50 USDC, and the first withdrawal is 400 USDC. The hypothetical conditions also assume sufficient market capacity, sufficient available liquidity, and successful transaction settlement.

Supplying 1,000 USDC leaves 250 USDC in the wallet and creates a 1,000 USDC position. Because USDC has 6 decimals, the contract receives 1,000,000,000 base units. When the hypothetical displayed position later reaches 1,012.50 USDC, the difference from the original supplied amount is 12.50 USDC of accrued balance.

Withdrawing the hypothetical 400 USDC raises the wallet balance from 250 to 650 USDC and reduces the supplied position to 612.50 USDC. A later full withdrawal of that 612.50 USDC leaves zero supplied USDC and produces a final wallet balance of 1,262.50 USDC. The concrete reconciliation is therefore 1,250 USDC at the start plus 12.50 USDC accrued, ending at 1,262.50 USDC after the position closes.

Withdraw the underlying asset and close the position cleanly

An underlying-asset withdrawal reverses the supply path inside the same deployment and market. Select the recorded position, choose a partial amount or the displayed maximum, confirm the transaction, and inspect the receiving wallet balance after settlement. The pool releases principal plus accrued balance up to the position amount and available unborrowed liquidity. A supply-only position has no debt condition restricting the exit.

Withdrawing the same ERC-20 underlying asset requires 0 new token approvals and ordinarily uses 1 onchain withdrawal transaction. A V3 withdrawal from WETH to WETH follows that direct route. Choosing native ETH instead uses the WrappedTokenGateway, which withdraws WETH and unwraps it in a single transaction; WETH and ETH convert at a 1:1 token ratio through the wrapper.

Direct V3 contract integrations pass the withdrawal amount as a uint256 value. Setting that value to the maximum uint256 integer, 2 ²⁵⁶ −1, requests the full available balance instead of requiring an exact accrued amount. Interfaces expose the same intent through a maximum button and calculate the executable amount. A completed full exit leaves 0 supplied units in that market, restores the underlying token to the destination address, and produces a final withdrawal receipt for the position record.