Understanding DeFi transactions: how to tell what actually happened on-chain

Updated July 2026 · CryptoTaxEdge

A single DeFi transaction can swap tokens, mint a receipt, route a fee, and call three contracts, all under one hash. Reading it means separating what the wallet actually did from the machinery around it.

A plain transfer is honest about itself. One token leaves a wallet, one address receives it, and the transaction does exactly what it looks like. DeFi rarely stays that plain. Supplying to a lending pool, adding liquidity, or claiming a reward can each set off a chain of internal steps recorded under one transaction hash. The wallet history shows a single entry. The chain recorded a sequence. Reading a DeFi transaction is the work of turning that sequence back into a plain sentence: this wallet did this thing.

Start with the token transfers

Every asset that moved during a transaction is recorded as a transfer event in its logs. Transfers are the most reliable place to start, because they are what happened, not what a label claims happened. The habit worth building is to list the transfers from the wallet's point of view: what left, what arrived, and what the net change is.

Take a lending deposit. A wallet supplies 1,000 USDC to a pool. The logs show 1,000 USDC leaving the wallet and, in the same transaction, an interest-bearing receipt token arriving back. Two transfers, one economic action: a deposit into a position the wallet can later withdraw. A reading that sees only "1,000 USDC out" and stops has captured half the transaction and will likely record a disposal that never occurred.

Receipt tokens are the tell for a position

Many DeFi actions hand back a token that represents a claim. Liquidity provision returns an LP token. Lending returns an interest-bearing token such as an aToken or a cToken. Staking returns a staked-asset derivative. These receipt tokens are the signal that an asset was parked, not sold. Reading them correctly is what separates "sold USDC" from "deposited USDC and holds a claim to withdraw it". Treating a receipt token as a disposal is one of the most common DeFi errors, and one of the most consequential, because it invents a taxable event out of an ordinary deposit.

The function call tells you intent

Alongside the transfers, a transaction records which function was called on which contract. The function name is a strong hint about intent: deposit, withdraw, swap, addLiquidity, claim, stake, unstake. Two transactions can move the same tokens and mean opposite things depending on the method. Pulling collateral out of a lending protocol and borrowing against collateral can produce similar-looking transfer lists, but the called function tells them apart. Reading the method next to the transfers is how you separate a supply from a borrow, or a fresh claim from a compound.

Filter out the events with no economic substance

Not everything inside a transaction is an asset change worth recording. A few common cases add clutter rather than meaning:

• Approvals grant a contract permission to spend a token and move no assets at all.
• Wrapping and unwrapping, such as ETH to WETH and back, change the form of an asset without changing the underlying holding.
• Spam and dust tokens can appear in the logs of transactions that have nothing to do with them.

A careful read sets these aside so the ledger reflects real activity. Counting an approval as a transaction, or a wrap as a trade, pads the record with events that carry no substance and make everything downstream harder to check.

A worked example, open to close

Consider adding liquidity to a Uniswap v3 pool. The wallet calls a position-manager contract, the logs show two tokens leaving the wallet, say ETH and USDC, and an NFT representing the new position is minted back to the wallet. The naive read is "two disposals". The accurate read is "one liquidity position opened, funded with two assets, with an NFT as the receipt". When the wallet later closes the position, the mirror transaction returns the two tokens plus any fees earned and burns the NFT. Reading the opening and closing transactions as a pair is what makes the whole position legible instead of four disconnected token movements.

Why automated labels sometimes disagree

Different tools read the same transaction and occasionally reach different labels, because they weight different signals. One leans on the contract address, another on the function name, another on the shape of the transfers. When those signals point the same way, the label is trustworthy. When they conflict, the honest move is to surface the transaction rather than pick a winner in silence.

The payoff of reading transactions this way is a ledger that matches reality. Every position is opened and closed on the record, every receipt token is understood as a claim rather than a sale, and the handful of genuinely ambiguous transactions are the only ones that reach a human. You can see the full set of labels the engine uses, and the reasoning behind each, in the classification taxonomy.