Tracing Asset Flow Through Deposit, Protocol Use, and Withdrawal

Hello again. In the previous lesson, you mapped Aave V3 as a system: users interact through interfaces with the Pool, while aTokens, debt tokens, configuration contracts, oracles, and governance form the surrounding machinery. This lesson puts that map to work.

Our objective is to build an evidence-based asset trace. You will follow an illustrative USDC supply position from a user wallet into an Aave market, observe how the depositor’s claim is represented, identify how the pooled liquidity can be lent, and verify a later withdrawal. The method applies to other DeFi designs too, but Aave’s pooled lending model makes the distinction between an underlying asset and a user’s on-chain claim especially clear.

---

What it means to “trace an asset”

Suppose a user, Maya, supplies 100 USDC to an Aave V3 market on a specified chain. A casual description might be:

“Maya deposits USDC into Aave, earns yield, and later withdraws it.”

That is economically useful but too vague for due diligence. A trace replaces it with a set of verifiable statements:

Stage	What happened economically	What you should verify on-chain
Preparation	Maya authorizes a contract to spend USDC, if an allowance is needed.	An ERC-20 Approval event, including owner, spender, and amount
Supply	USDC leaves Maya’s wallet and enters the reserve’s custody arrangement.	A confirmed Pool transaction, underlying-token transfer, and supply-related events
Claim creation	Maya receives an aUSDC balance representing her claim on the reserve.	aToken mint or transfer events, plus Maya’s aToken balance
Protocol use	The pooled USDC may be borrowed by eligible users.	Borrow transaction, debt-accounting change, and transfer of USDC to the borrower
Repayment	A borrower returns principal and accrued interest to the reserve.	Repay transaction, USDC transfer back to the reserve, and debt reduction
Withdrawal	Maya redeems aUSDC for USDC, including accrued supplier interest.	Withdrawal transaction, aToken burn or reduction, and USDC transfer to the recipient

Two cautions matter from the beginning.

First, a pool is fungible. Once USDC is supplied, you generally cannot identify Maya’s particular token units and prove that those exact units were sent to a particular borrower. The meaningful trace is an accounting and custody trace: Maya contributed USDC, received a claim on the reserve, borrowers drew from the common reserve, and Maya later redeemed her claim.

Second, the transaction’s visible recipient is not always the contract that ends up holding the underlying token. In Aave V3, the Pool is normally the entry point for user actions, but the reserve’s aToken contract commonly serves as the on-chain custody address for the underlying asset. Do not infer custody from a front end label or from the transaction’s To field alone; verify it through the token-transfer records.

Before opening an explorer, establish the expected semantics from documentation.

The documentation tells you the protocol’s intended accounting model. The explorer supplies evidence that a particular transaction actually followed that model.

---

The asset trace as an accounting story

A reliable trace has three layers. Keep them separate in your notes.

1. Asset movement: Which address lost or gained the underlying token?
2. Position accounting: Which address gained or lost a receipt-token or debt-token balance?
3. Protocol meaning: Does the documented contract role explain why those movements occurred?

For the simple supplier case, the story is:

1. Maya holds USDC in her wallet.
2. She authorizes the approved spender to move up to a stated USDC amount, unless she is using a permit-based route or has an existing allowance.
3. She calls the Aave Pool’s supply operation.
4. USDC moves from Maya’s wallet to the reserve custody address.
5. Maya receives aUSDC, which records her claim on the pooled USDC and its accrued supplier yield.
6. Later, Maya calls the withdrawal operation. Her aUSDC position is reduced and USDC is sent to the chosen withdrawal recipient.

The borrower path connects Maya’s supply to protocol use, but not as a one-to-one transfer:

1. A borrower supplies eligible collateral.
2. The borrower calls the Pool to borrow USDC.
3. USDC leaves the reserve and arrives at the borrower or specified recipient.
4. The protocol records the borrower’s obligation through its variable-debt accounting.
5. On repayment, USDC returns to the reserve; the debt position falls by the amount repaid.

Interest is not normally a stream of visible USDC transfers from each borrower directly into every supplier wallet. In Aave’s model, supplier yield is reflected through the aToken accounting. The documentation says that the aToken balance increases over time from borrowing activity in the pool. Therefore, do not expect to find a separate transfer log every time a supplier earns a tiny increment of interest.

A supplier trace is thus strongest when it establishes all of the following:

• the user’s underlying USDC decreased at supply;
• the reserve custody balance increased by the corresponding amount;
• the user’s aUSDC claim increased;
• the withdrawal later reduced or burned that aUSDC claim;
• the user or designated recipient received USDC back.

---

Learn the explorer’s evidence hierarchy

A block explorer displays several views of the same transaction. Each answers a different question.

For a DeFi asset trace, use the following hierarchy.

1. Transaction overview: did the intended call execute?

Begin with a transaction hash, not just a wallet’s displayed balance. Check:

• Network: An Ethereum transaction must be examined on Ethereum’s explorer. A transaction on an L2 needs that network’s corresponding explorer.
• Status: A reverted transaction did not complete the supply, borrow, repayment, or withdrawal. A wallet may have paid gas even though the intended asset movement failed.
• From: Which account authorized the call?
• To: Which contract received the call? For normal Aave operations, this should be the verified Pool or a documented router or gateway that calls it.
• Decoded input data: Does the function and its arguments describe a supply, withdrawal, borrow, or repayment? Pay close attention to the asset address, amount, recipient, and onBehalfOf-style account fields where shown.

The To field identifies the immediate call target; it does not independently establish where USDC ended up.

2. Event logs: which contracts recorded what?

Event logs are transaction receipts written by contracts during successful execution. For ERC-20 assets, the most important events are often Transfer and Approval.

The Approval-event screenshot illustrates an important distinction:

• Approval(owner, spender, amount) means the owner has authorized the stated spender to move up to a stated token amount.
• It does not mean the spender has moved those tokens.
• A later Transfer(from, to, amount) is the relevant evidence of a token movement.

Explorer interfaces often decode the event for you. Still, verify the contract address that emitted it. An event called Transfer emitted by a random token contract is not evidence of USDC movement. Match the emitter to the verified underlying USDC contract on the chosen chain.

In a standard ERC-20 event, the first log topic identifies the event type; additional indexed fields commonly include addresses such as sender, recipient, owner, or spender. Non-indexed values such as an amount may appear in the data field. You rarely need to decode hexadecimal manually, but you do need to know what the decoded labels are claiming.

3. Token transfer summaries: useful index, not final proof

Many explorers provide a “Token Transfers” tab. It is a convenient filtered presentation of token Transfer logs, so it is an excellent place to spot the likely movement quickly. For important conclusions, click through to the underlying log and check:

• the emitting token contract;
• sender and receiver addresses;
• raw token amount and displayed amount;
• whether the transfer occurs in the same confirmed transaction as the decoded Aave action.

If you need to reconcile an amount, remember that a token’s on-chain amount is an integer in its smallest units. The human-readable amount is:

$$\text{displayed amount}=\frac{\text{raw integer}}{10^{\text{token decimals}}}$$

USDC on many major deployments uses six decimals, but verify the particular token contract rather than applying that assumption automatically.

---

A practical trace procedure

Use a spreadsheet, notes document, or investigation template. The goal is to make each conclusion reproducible rather than relying on a screenshot or memory.

Step 1: freeze the scope

Record:

Field	Example
Protocol and version	Aave V3
Chain and market	One named Aave V3 deployment on one network
Underlying asset	The exact USDC contract address on that network
Receipt token	The market’s corresponding aUSDC contract address
Main action contract	The verified Pool address for that market
User account	The wallet whose position is being traced
Observation time	Date and block range examined

Names are not sufficient. The same ticker can refer to unrelated tokens on different chains, and protocols may operate distinct markets on several networks.

Step 2: locate the authorization, but do not confuse it with supply

Search the user’s history for a USDC Approval event before the supply transaction. Record the owner, spender, allowance, transaction hash, and time.

Then ask:

• Is the spender actually the expected Pool, gateway, or documented intermediary?
• Is the allowance at least as large as the intended supply?
• Is this a fresh approval, an increase to an existing approval, or a reduction to zero?

An approval may be absent from the immediate sequence for legitimate reasons: an earlier allowance may still exist, or the transaction may use a permit mechanism. Its absence is therefore not proof that the supply failed. Conversely, approval alone is never proof that a supply happened.

Step 3: prove the supply with a three-part match

Find the supply transaction and inspect its decoded input. It should identify the underlying asset, amount, and the account receiving the aToken position. Next, inspect the logs and build this mini-reconciliation:

Evidence	Expected observation	What it establishes
Pool action	A successful supply-related call or event	The protocol operation requested and executed
Underlying USDC transfer	Maya’s wallet decreases; reserve custody address receives USDC	The underlying asset moved into the reserve arrangement
aUSDC accounting	Maya receives or is minted aUSDC	Maya acquired a supplier claim

The three records should agree on the asset, beneficiary, and approximate amount. “Approximate” matters because interest-bearing accounting, token decimals, and any pre-existing balance can make a displayed wallet balance a poor substitute for the transaction-level amount.

At this point, write a conclusion with appropriately limited language:

Transaction [hash] successfully supplied [amount] of the verified USDC token on [chain]. The Pool processed the action; the underlying transfer reached the reserve custody address; and the specified beneficiary received the corresponding aUSDC claim.

That is a defensible claim. “Maya’s money is safely held by Aave” is not: it introduces a risk judgment that the transaction alone cannot prove.

Step 4: observe pooled use through a borrow and repayment

To trace protocol use, find a separate USDC borrow transaction from the same market. It need not involve Maya’s address; in a pooled reserve, the supplier does not select a particular borrower.

For the borrower’s transaction, look for:

• a successful borrow action at the Pool;
• underlying USDC transferred out from the reserve custody arrangement to the borrower or designated recipient;
• a debt-accounting increase for the borrower, often shown through debt-token events and the protocol’s borrow event.

For repayment, reverse the evidence pattern:

• USDC moves from the repayer to the reserve;
• the borrower’s debt accounting decreases;
• a successful repayment-related Pool event is emitted.

This proves the reserve’s liquidity cycle. It does not prove that Maya financed one particular borrower. The sound conclusion is that Maya’s aUSDC is a pro rata claim on a pooled reserve whose liquidity is used for eligible borrowing under the protocol’s rules.

Step 5: prove withdrawal and reconcile the ending position

Locate the withdrawal transaction. Its decoded call should show the amount and recipient. Then confirm:

1. the aUSDC balance was burned or reduced for the withdrawing account;
2. USDC moved from reserve custody to the recipient;
3. the transaction succeeded on the correct network.

The recipient deserves special attention. A withdrawal can be sent to an address other than the account initiating the transaction. A trace should state both the position owner and the underlying-token recipient.

If Maya had used her supplied USDC as collateral for an open loan, Aave can restrict a withdrawal that would make her account insufficiently collateralized. Separately, even a supplier with no debt cannot withdraw more underlying liquidity than is currently unborrowed in the reserve. These are distinct explanations for why a displayed aToken position may not be immediately redeemable in full.

---

A compact evidence record—and common false conclusions

After tracing the transactions, produce a short record like this:

Claim	Evidence to cite	Remaining uncertainty
User supplied USDC	Supply transaction, USDC transfer log, aUSDC mint or receipt event	Whether the user understood all protocol and market risks
User held a supplier claim	aUSDC balance and contract identity	Current redeemable amount under changing reserve liquidity
Reserve was used for lending	Independent borrow and repayment records in the same reserve	Which suppliers economically funded a specific borrow
User withdrew USDC	Withdrawal transaction, aUSDC reduction, USDC receipt	Whether all historical deposits and withdrawals have been captured

Avoid these recurring errors:

• “The transaction says Pool, so Pool holds the USDC.”
  The To field identifies the entry contract. Use transfer logs to establish the token’s recipient and current custody arrangement.

• “An Approval proves the protocol took funds.”
  Approval grants spending authority. Only a later transfer proves movement.

• “An aToken is the underlying token.”
  It is a claim on the reserve, not the original USDC. It has separate contract identity and transfer history.

• “I can follow my exact USDC to a borrower.”
  In a pooled market, deposits are commingled. Trace the supplier’s claim and aggregate reserve flows instead.

• “A transaction succeeded, so withdrawal was risk-free.”
  Success proves execution, not the absence of smart-contract, oracle, governance, liquidity, or underlying-token risks.

• “No visible interest-transfer event means no yield.”
  Interest-bearing receipt-token systems can update a user’s effective balance through protocol accounting rather than a continuous series of transfers.

A useful final discipline is to label every statement as one of three types:

• Observed: directly visible in a transaction, log, or balance query.
• Documented: described by official protocol documentation.
• Inferred: a conclusion combining observed records with documented behavior.

For example, “USDC moved from the user wallet to the reserve custody address” is observed. “aUSDC represents a supplier’s interest-bearing claim” is documented. “The user became a supplier in this Aave reserve” is a justified inference.

---

Key takeaways

A DeFi asset trace is not a hunt for a single “deposit” label. It is a reconciliation across transaction calls, token transfers, position-token accounting, and documentation.

For an Aave-style supply position:

• an approval authorizes a spender but does not move assets;
• a successful supply moves the underlying token into the reserve’s custody arrangement and creates an aToken claim;
• a borrower can draw from the pooled reserve, receiving underlying tokens while incurring a debt position;
• borrower repayments support the reserve’s accounting and supplier yield;
• a successful withdrawal reduces or burns the supplier’s aToken claim and transfers underlying tokens to the withdrawal recipient;
• explorer evidence must always be checked against the correct chain, verified contract addresses, and decoded transaction details.

In the next lesson, you will use this concrete trace to distinguish four risks that can exist even when every transaction is correctly confirmed: custody risk, settlement risk, counterparty risk, and smart-contract risk.