Aave

Practical guides

Aave is a transaction preview followed by onchain position verification

Aave is an interface where a proposed supply or borrow becomes real only after a wallet authorizes the correct contract call and the selected network confirms the call. The preview names the asset, amount, market, rate inputs, collateral effect, and estimated network fee; it is not a receipt. A transaction hash, successful receipt status, protocol events, and the resulting supply or debt balance provide the onchain evidence that the intended position change actually executed.

Posted 5 Aug 2026

From amount entry to a confirmed V3 position

The Aave V3 transaction path moves through three distinct states: previewed, authorized, and confirmed. The preview is a prepared proposal based on the chosen market and recently read onchain data; authorization is a signature or transaction request; confirmation is a mined state transition carrying a successful receipt.

Entering an amount makes the interface validate the wallet balance, reserve status, available liquidity, caps, collateral configuration, and expected account effect. A standard ERC-20 supply or repayment may require two onchain transactions: one allowance approval and one protocol action. An EIP-2612 permit replaces the first transaction with an offchain signature, leaving one onchain action to execute.

The walkthrough here follows V3 on EVM networks, where Pool calls, aTokens, variable debt tokens, and event logs expose a clear verification trail. Aave Pro V4 uses hubs, spokes, and different position objects, so its contract target and event set belong to that version's transaction record.

How the network-fee preview is formed

The network-fee preview estimates what the selected blockchain will charge to execute the prepared contract call. That fee is separate from the supply or borrowed amount and is paid with the network's native fee asset, such as ETH on Ethereum, Arbitrum One, Base, and Optimism.

An EIP-1559 type-2 transaction carries two fee caps: the maximum fee per gas and the maximum priority fee per gas. The eventual charge equals gas used multiplied by the effective gas price, while the wallet's gas limit multiplied by its maximum fee represents a higher spending bound. One gwei equals 10 ⁹ wei, and one ETH contains 10 ¹⁸ wei.

A permit or other message signature does not consume network gas because it is not broadcast as a transaction. A wallet rejection also costs nothing. A broadcast call that executes unsuccessfully receives receipt status 0 and still consumes gas, whereas a successful call carries status 1. The displayed estimate changes with network demand and the exact execution path.

Matching the wallet, chain, and market

A wallet-chain-market match determines which balances, allowances, contracts, and positions the interface reads. Ethereum Mainnet uses chain ID 1, Optimism uses 10, Polygon PoS uses 137, Arbitrum One uses 42161, Base uses 8453, and Avalanche C-Chain uses 43114.

MetaMask, Ledger, and Safe represent different signing arrangements even when they control the same kind of EVM position. WalletConnect transports the connection session between an interface and a compatible wallet; it does not combine balances, approvals, or histories from separate networks.

The same hexadecimal account may appear on every EVM network, yet each chain maintains independent assets and protocol state. Selecting Base while the wallet remains on Ethereum therefore produces a setup mismatch rather than a view of one combined account.

What the supply preview commits to changing

The supply preview identifies the reserve, underlying token, input amount, available wallet balance, supply-rate snapshot, collateral choice, and fee estimate. Its amount must be interpreted with the token contract's precision: USDC uses 6 decimals, while WETH uses 18 decimals.

After successful execution, the underlying ERC-20 balance leaves the sender, the Pool records the supply, and the designated position owner receives the corresponding aToken balance. In Aave V3, a supply call mints aTokens at a 1:1 ratio to the underlying amount transferred into the reserve. The aToken uses the underlying asset's decimal precision, so aUSDC follows 6 decimals and aWETH follows 18.

The displayed aToken balance then incorporates accrued supply interest through the reserve's liquidity index. Enabling the asset as collateral is a separate position property, represented by the collateral selection or a later toggle transaction. An approval receipt by itself changes only the ERC-20 allowance; it creates no supply position.

What the borrow panel predicts before confirmation

The borrow preview projects the borrowed amount, variable rate, available liquidity, collateral capacity, resulting health factor, recipient asset, and network fee. Each displayed value belongs to one market and one wallet address, so a position on Ethereum does not support a borrow prepared for Arbitrum One.

Successful V3 execution sends the underlying asset, such as USDC, WETH, or GHO, to the recipient and mints variable debt tokens to the position owner. The Pool's interest-rate mode is encoded as value 2 for variable borrowing. That debt token is non-transferable, tracks principal plus accrued interest, and uses the same decimal precision as its underlying asset.

A health factor exists once the account has active debt, and 1 is the protocol boundary at which the position becomes eligible for liquidation. The preview's health factor is a projection rather than a reserved outcome: oracle values, utilization, and the account's state are checked again when the transaction executes. That adjacent threshold matters to confirmation, while liquidation mechanics remain a separate position-management subject.

Approval signature or approval transaction?

An ERC-20 approval authorizes a named spender to transfer up to a stated token allowance from the owner. For a direct supply or repayment, the spender is the relevant Pool or execution contract, and the allowance applies only to that token contract on that chain.

A regular approval is an onchain transaction. Once confirmed, a sufficient existing allowance lets the protocol action proceed as one further transaction. Without that allowance, the complete sequence contains two transactions. Approval does not move the tokens and does not prove that the supply or repayment followed.

An EIP-2612 permit signs an owner, spender, value, nonce, and deadline under EIP-712 typed data. The nonce makes a consumed permit unusable a second time, while the deadline limits how late it remains valid. Permit support belongs to the underlying token implementation; the interface therefore offers this path only when the reserve's token supports it.

Reading the wallet confirmation as a contract request

The wallet confirmation is the final readable description of the transaction before broadcast. It should expose the active chain, sending account, destination contract, native value, encoded method data, gas limit, and fee settings, although presentation depth differs between MetaMask, Ledger, Safe, and other signers.

An EVM contract address is 20 bytes, written as 40 hexadecimal digits or 42 characters when the 0x prefix is included. The complete address matters because shortened labels conceal most digits. The Aave Address Book identifies deployed protocol contracts for each market, while the asset contract identifies the token whose allowance is being changed.

An approval normally targets the ERC-20 token contract and encodes an approve call. A supply targets the Pool or an approved execution component, while a native-token route may target a gateway that wraps or unwraps WETH. A zero native-value field is normal for many token calls because the asset amount sits inside calldata rather than the transaction's ETH value.

Verifying the receipt, contract, and event logs

An onchain receipt establishes whether a submitted transaction executed and where it was included. The transaction hash is 32 bytes, displayed as 64 hexadecimal digits or 66 characters with its 0x prefix; it is the durable lookup key for explorers such as Etherscan and Blockscout.

Receipt status 1 confirms successful EVM execution, but the method and logs determine what succeeded. A V3 supply produces a Pool Supply event with associated underlying-token and aToken activity. A borrow produces a Pool Borrow event, transfers the underlying asset to the recipient, and records variable-debt minting for the position owner.

Verification therefore joins several facts: the expected chain, sender, destination contract, decoded method, asset address, amount, position owner, status, and protocol events. A plain ERC-20 transfer to a contract may also receive status 1, yet it does not become a repayment unless the protocol's repay method executed and the corresponding debt state changed.

Reconciling the dashboard with token balances

The position dashboard is a formatted view of onchain state indexed by four coordinates: wallet, chain, market, and reserve. Selecting the wrong value in any one coordinate produces an empty or apparently inconsistent view even when the receipt is valid elsewhere.

For V3 supplies, an aToken balanceOf call returns principal plus accrued interest through the liquidity index. A variable debt token's balanceOf returns principal plus accrued variable interest. Those values change through index-based accounting without requiring a new wallet transaction for every increment, so an explorer's original transfer amount is not the permanent position balance.

The Aave Labs interface also relies on RPC responses and indexed market data, which may refresh after the receipt becomes available. Once the transaction is confirmed, reload the selected market and compare its account address with the receipt sender or on-behalf-of address. A direct JSON-RPC read of the relevant token balance provides an additional state check when the dashboard cache is behind.

Recovering from a wallet and interface network mismatch

A network mismatch occurs when the interface prepares one market while the wallet signs on another active chain. The appropriate recovery is to align the selected market and wallet network, discard the old modal, and generate a fresh preview from the newly selected chain state.

Approve the wallet's chain-switch request, then confirm that the market label, native fee balance, token balance, and destination contract all changed to the intended deployment. If a WalletConnect session or browser wallet retains the previous network, reconnecting the session forces a new chain negotiation before another preview is built.

An approval issued on chain ID 1 remains an Ethereum approval; it supplies no allowance on chain ID 8453 or 42161. EIP-155 binds a signed transaction to its chain ID, so an already signed request cannot be transported to another network. Re-entering the amount after the switch also refreshes caps, liquidity, and fee data.

Handling stale previews and pending replacements

A stale transaction preview reflects state that changed after preparation. Rebuild it after an intervening approval, collateral toggle, repayment, borrow, account switch, reserve update, or material delay, because the Pool validates the latest state during execution rather than preserving the earlier screen values.

A rejected wallet request has no hash and changes nothing. A broadcast request with a hash remains pending until it is included, replaced, or dropped. Replacing an EOA transaction uses the same nonce with new fee settings; sending a different protocol action at the next nonce does not cancel the first request.

Wait for the receipt before repeating a position change. If the original transaction later confirms, a second independently signed action represents another state transition rather than a retry. The completed decision trail is a fresh preview, an intentional authorization, a successful receipt, the expected protocol events, and a matching position balance.