Aave is network-specific at transaction confirmation

Supplying USDC from a wallet already on Base

A Base supply starts with USDC and ETH in the same wallet address. The interface reads Base balances, then prepares an ERC-20 authorization and the Pool supply call.

Choose the Base market before selecting USDC. Enter the token amount, read the displayed supply rate and collateral status, then open the wallet request. A first supply has two authorization stages: permission for the Pool to transfer USDC and confirmation of the supply itself. The interface handles the sequence, yet each wallet screen represents a different action.

The connection signature is off-chain, costs zero gas, and moves nothing. An allowance signature also avoids an immediate network fee when the token supports the offered permit path. The supply remains an on-chain transaction. Base charges its execution fee in ETH, so a wallet holding only USDC cannot complete that last step. That distinction explains many apparently inactive confirmation buttons.

Network identity comes before token identity

A chain ID identifies the exact ledger that will process a transaction. The selected Aave market and the wallet network must resolve to the same chain ID before signing. The wider context is laid out in Aave liquidations.

Ethereum Mainnet uses chain ID 1, while OP Mainnet uses 10. Polygon PoS uses 137, Base uses 8453, Arbitrum One uses 42161, and Avalanche C-Chain uses 43114. These deployments hold separate reserves and separate positions. USDC on Base therefore cannot fund an Ethereum Mainnet supply merely because both interfaces show the ticker USDC.

The same externally owned account often appears on several EVM networks. Its address contains 20 bytes, displayed as 40 hexadecimal characters after the 0x prefix, or 42 characters in total. Matching that address is necessary, but it does not establish the network. Read both the account and chain label. The numeric chain ID provides the decisive cross-check when a wallet exposes it.

Wallet connection and wallet recovery are separate choices

Wallet connection selects the account that signs the supply. Wallet recovery determines how that signing authority returns after a device reset or replacement.

The interface accepts common EVM sessions, including MetaMask and connections relayed through WalletConnect. Ledger and Trezor accounts add device confirmation while preserving the same address, chain ID, and contract call. The connection method does not alter the Pool's accounting. It only changes where transaction details appear and where the signature is produced.

MetaMask creates a 12-word recovery phrase, and Ledger devices generate 24 words. Trezor supports 12- or 24-word BIP-39 backups plus 21-word SLIP-39 backups on compatible models. BIP-39 draws from a fixed 2,048-word list; SLIP-39 uses 1,024 words and also supports share thresholds. None of those words belongs in a connection, approval, or supply confirmation screen.

Approval and supply are different confirmations

An ERC-20 approval sets an allowance; it does not supply the token. Aave separates that permission from the Pool call that transfers the chosen amount into the reserve.

The standard approve function carries two arguments: a spender address and an unsigned 256-bit value. Here, the spender is the Pool contract shown by the wallet. The allowance belongs to one owner, one token contract, one spender, and one chain. An approval on Ethereum Mainnet has no effect on Base, even when the wallet address matches.

If the interface offers an EIP-2612 permit, the wallet signs typed data containing the value, nonce, and deadline. That signature costs no gas by itself. The later supply transaction consumes it. With a conventional approval transaction, the approval must settle before the supply can spend the token. Any allowance left above the supplied amount stays active until another approval changes it.

Gas details reveal whether confirmation can settle

Gas review shows whether the selected account can pay the network that executes the supply. An Aave supply needs the native gas asset even when the supplied asset is an ERC-20 stablecoin.

Ethereum Mainnet, Base, OP Mainnet, and Arbitrum One charge fees in ETH. Polygon PoS uses POL, while Avalanche C-Chain uses AVAX. Wallets normally display a gas limit and an estimated total. On EIP-1559-style networks, the effective price reflects the base fee and priority fee, bounded by the submitted maximum; some rollups also expose a separate data component.

One gwei equals 10^9 wei, while one ETH equals 10^18 wei. A plain native-asset transfer has a 21,000-gas intrinsic baseline. A Pool supply is a contract call with token transfer, reserve updates, and aToken minting, so it executes more work. The wallet's maximum is not automatically the final charge: unused gas is not spent, while a rejected transaction before submission creates no on-chain fee.

The amount preview must match the token's precision

Token precision determines the integer placed inside the supply call. The amount preview should show the same asset, network, and human-readable quantity that the user entered.

USDC uses 6 decimals, so one USDC equals 1,000,000 base units. WETH uses 18 decimals. ERC-20 transfers encode the amount as a 256-bit unsigned integer, and the interface performs the decimal conversion before asking the wallet to sign. A symbol match without a network match is insufficient because each chain has its own token contract and balance.

Read the amount separately from the fee. Supplying USDC does not subtract gas from the USDC quantity; Base or Ethereum charges ETH alongside it. The displayed rate, remaining supply capacity, and gas estimate are live inputs rather than fixed transaction constants. If capacity closes before execution, the Pool call reverts instead of partially accepting a smaller amount.

A successful supply changes three protocol balances

A successful Aave supply reduces the wallet's underlying-token balance, increases reserve liquidity, and mints the corresponding aToken position to the beneficiary. Those changes settle atomically on one chain.

In the V3 Pool interface, the supply function has four inputs: asset, amount, beneficiary, and a 16-bit referral code. The ordinary interface uses the connected account as beneficiary. The underlying token moves into the reserve's aToken custody address, then the aToken contract records the supplied position. If any validation fails, the whole call reverts and none of these protocol balance changes remains.

An aToken uses the underlying asset's decimal precision. A USDC reserve therefore exposes a 6-decimal aToken, while WETH uses 18 decimals. The visible aToken balance is calculated from a scaled balance and the reserve's liquidity index, allowing accrued supply interest to appear without a new wallet transaction. The receipt also carries the Pool Supply event and token transfer logs.

Collateral status is a separate account setting. An eligible reserve may appear enabled as collateral after supply, subject to its configuration and the account's existing mode. That label does not alter the amount deposited. It affects later account calculations, so it deserves a deliberate read before moving on.

Receipt verification and wrong-network recovery

Transaction verification requires a successful receipt and a matching on-chain position. The Aave dashboard is a convenient view, while the receipt is the settled record for the chosen network.

An EVM transaction hash contains 32 bytes, rendered as 64 hexadecimal characters after 0x, or 66 characters total. Search that hash in the explorer for its chain: Etherscan for Ethereum Mainnet, Basescan for Base, or Arbiscan for Arbitrum One. Confirm receipt status 1, the connected account, the Pool target, the supplied token amount, and the Supply event. Status 0 means the state changes reverted, though execution gas was consumed.

The common setup error is selecting a market on one chain while the wallet remains on another. Switch the wallet to the market's chain, reconnect the intended account, and reopen the asset panel. If the token balance still reads zero, the tokens are on a different ledger. Switching networks changes the view; it never bridges the asset.

A transaction already confirmed on another supported deployment is not lost. Return the wallet and dashboard to that original chain, then inspect the aToken position there. A fresh supply on the intended network requires tokens and native gas on that network. This recovery path preserves the existing position and prevents a second confirmation from being mistaken for a correction of the first.