Internal transactions and smart contracts

A beginner analyst opens an address in an explorer, sees a short list of three transfers — and concludes "the wallet is almost empty, nothing interesting." In reality millions of dollars passed through this address; they simply moved as internal transactions, which aren't on the ordinary tab. This is one of the most common blind spots for newcomers. In this lesson we'll cover what internal txns are, why they aren't visible, how smart contracts (DEXes, bridges) move funds, and where to look at all of this properly.

Two types of transactions in Ethereum

To understand internal transactions, you need to distinguish who initiates the transfer:

An external transaction (external / normal). It is created and signed by a human with their private key from an ordinary wallet (an EOA — externally owned account). Only such transactions are written to the blockchain as separate records with their own hash. These are exactly what the "Transactions" tab shows.
An internal transaction (internal). It is initiated by a smart contract in the course of executing code triggered by an external transaction. It has no hash of its own and no signature of its own — it's a side effect of the contract's operation.

The key idea: an "internal transaction" is not a separate record on the blockchain but an event within an execution. That's why you can't see it just by scrolling through the ordinary list of transfers.

Why they aren't visible in the ordinary list

The blockchain stores only external transactions — those signed by users. The ETH movements a contract makes during its operation are not recorded anywhere as standalone lines. So how do explorers like Etherscan show an "Internal Transactions" tab? The answer matters for understanding the whole mechanism.

Internal transactions are a reconstruction. Explorers don't "read" them from the blockchain directly. They re-execute (trace) each transaction on their own copy of the EVM and record all internal calls in which ETH is transferred. Therefore: (1) internal transfers exist only for the native currency (ETH) — don't confuse them with ERC-20 tokens, which move via Transfer events; (2) if a service doesn't do tracing, it doesn't see these movements at all.

An analogy. An external transaction is like the command "start the vending machine." Inside itself the machine dispenses a can, counts out change, turns on the lights — those are internal actions. Only your command is written in the log, and everything the machine did internally has to be reconstructed by "replaying" its operation.

How contracts move funds: DEX

Let's look at the most common case — a swap on a decentralised exchange (DEX), for example Uniswap. A user exchanges ETH for the token USDC. What actually happens?

The external transaction. The user sends ETH to the Uniswap router contract address and calls the swap function. This is the only record visible in their ordinary list. "Sent ETH to 0xUniswap..." — and that's all.
The internal transfers. Inside the execution, the router contract calls the liquidity-pool contract, the pool sends USDC to the user, and part of the ETH is distributed along the way. All these movements are internal. They aren't visible on the normal tab.
The change return. If the user sent slightly too much ETH, the contract returns the remainder via an internal transaction back to their address. Also invisible in the ordinary list.

For AML this is critical. Imagine: an analyst sees that a suspicious address sent 10 ETH to Uniswap and "the trail ends there." In reality the contract returned USDC to this same address via an internal transaction, and the money lives on in a different token. Without viewing internal txns and token transfers, the "thread" is lost, and laundering through a DEX looks like a dead end.

How contracts move funds: bridges

It's even trickier with cross-chain bridges. A bridge accepts an asset on one network and issues the equivalent on another. This is a classic tool for breaking the trail: an analyst working with only one blockchain "loses" the money at the entrance to the bridge.

The mechanics of a bridge through an analyst's eyes

The deposit. The user sends ETH to the bridge contract on the Ethereum network. The external transaction is visible. On Ethereum the money is then "frozen" on the contract.
The event. The bridge contract emits a log event with the recipient's address on the target network (for example, Arbitrum). This isn't a transfer but a record in the logs — you have to know how to read it.
The issuance on the other network. The bridge's validator/relayer on the Arbitrum network sends the equivalent funds to the recipient's address. This is already an entirely different transaction on a different blockchain. The link between "before" and "after" exists only through the bridge's logic.

To avoid losing the trail through a bridge, the analyst must: (1) recognise the contract address as a known bridge; (2) read the event with the recipient's address; (3) switch to the target network and continue tracing there. This is exactly why a serious AML engine is multi-chain and knows the addresses of popular bridges.

Where and how to look at this

Now for the practice — how an analyst actually finds the hidden movements.

The "Internal Transactions" tab on Etherscan. A separate tab next to the ordinary transactions. Here you see all ETH transfers initiated by contracts: DEX returns, payouts, distributions.
The "Token Transfers" tab (ERC-20 / ERC-721). Token movements aren't reflected in either normal or internal — they have their own tab, built from Transfer events. To skip it is to miss that an address holds millions in USDT.
Trace / "State" and debug tools. For a deep breakdown of a complex transaction (many nested calls), analysts use tracers: the "State" tab, Tenderly, Phalcon. They show the full call tree of contract → contract.
Logs and events (Logs / Events). This is exactly where the data of bridges, swaps and deposits is read — things that aren't direct transfers but carry key information about addresses.

The analyst's practical checklist. On opening any EVM address, always check at least four tabs: Normal, Internal, Token Transfers (ERC-20), NFT Transfers. Judging a wallet "empty" from the Normal tab alone is a gross error that causes whole layers of laundering to be missed.

An end-to-end example: laundering through a DEX and a bridge

A scheme that's easy to miss.
Hack → the thief gets 100 ETH → external tx to Uniswap (only this transfer is visible) → internal: the contract issues 250,000 USDC to the thief's address (invisible on Normal) → token transfer: the USDC goes to the bridge contract → bridge event: the recipient on the Polygon network → laundering continues on another network.
An analyst looking only at the Normal tab on Ethereum will see just "sent 100 ETH to Uniswap" and decide the trail ended. In reality the money lives on, just in a different token and a different network.

Let's break down what saves the analyst at each step: the Internal tab shows the USDC return; the Token Transfers tab — the stablecoin's movement to the bridge; reading the bridge event — the recipient's address; the multi-chain approach — the continuation on Polygon. Remove any one of these tools and the scheme looks like a dead end, and the dirty money "vanishes."

Lesson summary. External transactions are created by a human, and only they are recorded on the blockchain; internal ones are ETH transfers that contracts make during execution, reconstructed by tracing. DEXes return funds in other tokens via internal transactions; bridges carry value between networks through events. For AML analysis to be honest, the engine must read internal txns, token transfers and event logs and work across several networks. When AMLConsensus doesn't "lose" the money at the entrance to Uniswap or a bridge, that is precisely the mechanism you've just studied in this lesson at work.

← Programme Programme →

This material is for educational purposes.