DeFi

DeFi is a first-position workflow from market selection to clean withdrawal

DeFi is an onchain position workflow in which a funded wallet selects one market, authorizes a contract, deposits the intended token, verifies the resulting receipt, and later reverses the same position. A clean first attempt keeps the chain, asset contract, position type, and receiving address consistent from entry through withdrawal.

From funded wallet to clean withdrawal

A first DeFi position follows a six-stage path: fund the wallet, select a market, authorize access, deposit, confirm the receipt, and reverse the action.

Set the execution context

Choose the network before opening any market screen. Record the wallet address, chain ID, input token contract, intended amount, and expected receipt type. Then match those identifiers in the signing window. A dashboard label helps orientation, while the contract address binds the action to a specific asset and deployment. Keep the first route narrow: one wallet, one chain, one protocol, and one position.

Submit one primary action

For an ERC-20 input, authorize only the protocol contract the deposit will call, then submit the deposit as the primary action. Aave V3 calls this supply; an ERC-4626 vault exposes deposit or mint; Curve adds liquidity to a pool; and Uniswap V3 mints a ranged position. Read the wallet preview for the asset, amount, contract, and receiver. A batched interface may package authorization and entry together, but the position should still resolve to one owner and one receipt after execution.

Reverse the receipt

Confirm the receipt before considering entry complete. Later, return through the same position view, choose the corresponding exit action, and send the underlying assets back to the original wallet. A vault share is redeemed, an Aave supply is withdrawn, and a Uniswap V3 position is decreased and collected. Check both sides: the receipt falls or disappears, and the underlying token balance rises at the receiving address.

The sequence changes when an interface batches calls, yet every underlying state change still belongs to the same chain-specific position lifecycle.

Market selection starts with the position receipt

Market selection begins with the receipt the contract creates, because that receipt determines how ownership appears and how the later withdrawal must be executed.

Aave supply balances

Aave V3 represents a supplied asset through an aToken balance tied to the wallet. Its Pool supply function takes four inputs: asset, amount, beneficiary address, and referral code. The corresponding withdraw function takes three: asset, amount, and destination. The aToken balance is fungible and updates as protocol accounting accrues, so the receipt is read as an amount rather than a unique object.

ERC-4626 vault shares

An ERC-4626 vault holds one underlying ERC-20 asset and issues fungible shares. Yearn V3 vaults provide a recognizable example of share-based positions. Entry targets either an asset amount through deposit or an exact share amount through mint. The share balance remains the ownership record even when its underlying asset equivalent changes.

Pool and range receipts

Curve pools issue fungible LP tokens, while Uniswap V3 wraps each ranged liquidity position as an ERC-721 token. The Uniswap V3 mint call returns four values: token ID, liquidity, amount of token0, and amount of token1. Its position also records two price boundaries, the lower tick and upper tick. Curve's LP token records a pool share rather than a named deposit amount.

The network must match every asset and contract

Network selection fixes the chain ID, token contract, protocol deployment, account balance, and transaction record used throughout the position's entire lifecycle without substitution.

Ethereum Mainnet uses chain ID 1, OP Mainnet uses 10, Base uses 8453, and Arbitrum One uses 42161. These identifiers separate states even when a wallet displays the same account address. A USDC balance on Base and a USDC balance on Ethereum Mainnet belong to different token contracts and ledgers.

An EVM account address contains 20 bytes, displayed as 40 hexadecimal characters after the prefix. Match the complete address, not the shortened wallet label. A position cannot be reconstructed from the address alone; chain ID supplies the missing namespace. Moving an asset across chains starts another chain-specific record with its own receipt and balance.

Position prerequisites keep the first action legible

Position prerequisites are complete when one wallet controls the input asset on the selected chain and holds the chain's native execution token. Confirm the exact token contract, usable balance, intended market, receiving address, and expected receipt before signing. USDC uses 6 decimal places, while WETH uses 18; one ETH also equals 10 ¹⁸ wei. These units explain why raw contract amounts look unlike wallet displays. If the market accepts WETH, keep the input wrapped until the position action finishes.

Token standards determine the wallet sequence

Token standards define whether entry needs an ERC-20 allowance, returns fungible vault shares, or produces a uniquely identified ERC-721 position token in the wallet.

ERC-20 exposes six required core methods and two standard events, Transfer and Approval. The allowance permits a named spender to move up to an authorized amount through transferFrom. Setting a new approval overwrites the previous allowance for that owner-spender pair.

ERC-4626 defines one underlying ERC-20 asset and four state-changing methods: deposit, mint, withdraw, and redeem. It also defines two lifecycle events, Deposit and Withdraw. ERC-721 provides two approval routes: approval for one token ID and operator approval for every token owned by the caller. A permit-enabled route changes authorization packaging, while the resulting receipt standard remains the same.

One primary action should create one legible position

A first transaction should perform one primary position action, leaving the wallet with a receipt whose amount and owner are independently readable after execution.

Enter the exact amount in token units, confirm the receiver, and submit the action the selected market names. Aave V3 supplies one asset, an ERC-4626 vault deposits one underlying asset, Curve accepts the pool's defined token set, and Uniswap V3 mints against two tokens and two range boundaries. Do not treat the button label as proof. The transaction output must point to the expected receipt balance or token ID.

Complex routing belongs later. The first position should make its ownership record, asset movement, and reversal path obvious enough to reconcile without another transaction.

Transaction confirmation has three separate proofs

Transaction confirmation requires three checks: inclusion in a block, successful execution status, and a matching position balance recorded for the wallet address.

An Ethereum transaction hash is 32 bytes, rendered as 64 hexadecimal characters after the prefix, and identifies one submitted action. Ethereum divides time into 12-second slots and groups 32 slots into one 6.4-minute epoch. Inclusion timing still reflects whether a block appears in a slot, so elapsed time alone does not prove execution.

Read the transaction status first, then inspect logs and final balances. A successful approval changes allowance but creates no position receipt. A successful deposit moves the input asset and creates or updates ownership state. Both proofs must describe one position.

The position must be read from onchain state

Position state should be read from the relevant contract, because dashboards merely format balances, shares, token IDs, and asset amounts already stored onchain. The related figures are collected in DeFi eligibility breakdown.

Aave V3 exposes the aToken balance for a supplied asset. An ERC-4626 vault exposes balanceOf for shares and conversion views for underlying assets. Curve exposes the LP token balance. Uniswap V3 uses the NonfungiblePositionManager: its positions view returns 12 fields, including token0, token1, two ticks, liquidity, and two owed-token counters. The token ID uses the 256-bit unsigned integer type defined by ERC-721. Together, owner, receipt identifier, and asset contract provide a durable position record even when an interface is disconnected.

Write down the chain ID, protocol, receipt contract, token ID when present, and entry transaction hash. If a dashboard and contract view disagree, the confirmed contract state controls the next action.

A clean exit reverses the exact position type

A clean withdrawal applies the exit method belonging to the receipt: redeem shares, withdraw supplied assets, or unwind and collect a liquidity position.

Aave supply withdrawal

Aave V3 sends the underlying asset to the destination passed into its three-argument withdraw call. Select the same reserve the original aToken represents, choose the amount, and confirm the destination. The aToken balance falls as the underlying balance rises.

ERC-4626 share redemption

ERC-4626 offers two exit directions. withdraw targets an exact underlying asset amount, while redeem targets an exact share amount. Each method takes three inputs covering quantity, receiver, and owner. The Withdraw event records both assets and burned shares.

Uniswap V3 range removal

Uniswap V3 first decreases position liquidity, then collects the two token amounts owed to the recipient. Interfaces may batch those calls. Burning the ERC-721 record requires three zero conditions: liquidity, tokens owed for token0, and tokens owed for token1. After those three values reach zero, the burn call removes the token ID (detailed in DeFi wallets rundown ).

Partial withdrawal preserves the remaining receipt

Partial withdrawal reduces the receipt while preserving the same ownership record, provided the market supports incremental exits and the requested amount remains available. Aave V3 burns the corresponding aToken amount; ERC-4626 burns shares calculated for the requested assets; and Uniswap V3 subtracts a chosen liquidity amount from the same token ID. Recheck the remaining receipt and returned underlying balance after execution. The clean-exit target changes from zero to the exact remainder the wallet intends to keep.

The final record should reconcile four state changes

Position closure is complete when the underlying assets return, the receipt reaches its intended remainder, and the final transaction record matches both changes.

Reconcile four items: the withdrawal hash, successful status, receiving address, and post-withdrawal receipt. Then compare the underlying token contracts against the original input contracts. WETH may return as WETH rather than native ETH, and a two-token Uniswap V3 position returns token0 and token1 separately. A zero-liquidity NFT still remains until its two owed-token counters are collected and the NFT is burned.

A clean DeFi withdrawal leaves a reproducible record: entry transaction, receipt identifier, exit transaction, and final balances all describe the same position without another market action.