1 Transaction, 4 Transfers: Inside Internal Transactions
Internal transactions explained. Learn why they don’t appear in wallets and how block explorers reveal hidden value flows inside smart contract calls.
When you send a transaction from your wallet, it looks simple.
You click a button.
You confirm.
Your wallet shows one transaction.
But under the hood, that single transaction may trigger multiple contract calls, value transfers, and execution steps that your wallet never shows you.
These are called internal transactions.
In this guide, you’ll learn:
- What internal transactions are
- Why they don’t appear in wallets
- How block explorers surface hidden value flows
- How to read them in a real example
Let’s examine a real transaction on Soneium and break it down step by step.
What Are Internal Transactions?
An internal transaction is a contract-triggered call that happens during the execution of a regular blockchain transaction. It is not a separate transaction. It does not have its own transaction hash, it is not signed by a user, and it does not appear independently in a block.
Instead, internal transactions are generated inside the EVM when a smart contract calls another contract or transfers value during execution. You sign one transaction, but the contract may execute many actions internally as part of that single request.
Block explorers reconstruct and display those internal calls using execution trace data. Wallets typically show only the final result. Explorers show the execution.

Why Internal Transactions Don’t Appear in Wallets
Wallets are designed to give you a clear and simple view of your activity. They focus on the actions you directly take and the outcomes that affect your address. That typically includes transactions you sign, tokens sent to or received by your address, and your final balance changes after a transaction is confirmed.
This design is intentional. Wallets prioritize usability and clarity. Most users want to know: Did my transaction go through? How much did I spend? What did I receive? They are not built to expose the full execution mechanics happening inside the blockchain.
What wallets do not index is the deeper execution layer of a transaction. They do not surface the EVM call stack, which records how contracts call other contracts during execution.
They do not display nested contract calls that happen internally after you trigger a function. They also do not show delegate calls, which are commonly used in proxy contract architectures. Most importantly, wallets do not reconstruct or display full execution traces.
Internal transactions live inside that execution trace. They are not standalone entries in a block. Instead, they are derived from the detailed step-by-step execution data produced when a transaction runs inside the EVM. Block explorers access this node-level trace data, reconstruct the internal calls, and present them in a readable format. That is why explorers can reveal value flows and contract interactions that wallets simply do not display.
That’s why your wallet might show:
Sent 0.00032 ETH
But an explorer shows:
That 0.00032 ETH was split across multiple internal calls.
To see this clearly, let’s look at a real example.
A Real Example: Registering a Domain on Soneium
There are many domain name providers across different blockchain networks. For this example, we’ll use InfinityName, a domain provider on Soneium.
InfinityName allows users to register human-readable names instead of long hexadecimal wallet addresses. Instead of sending funds to a complex 0x string, you can send to something readable and easier to verify.
Human-readable names improve usability and safety. They make it easier to confirm you’re sending funds to the correct destination and reduce the risk of mistakes or address poisoning attacks that rely on lookalike wallet strings.
Now let’s look at a real domain registration transaction.
Step 1: Overview of Transaction

If you were only looking at the wallet transaction history when you purchase an onchain domain name, all you'd see is essentially
- One transaction
- Amount of ETH sent
- Transaction ID & link
But that is not the full story. If you navigate to the transaction details in a block explorer, we can start to dig deeper.
On the Overview tab, we see:
- Method: Register
- Contract: InfinityNameUpgradeable
- Value sent: 0.00032 ETH
- Status: Success
- Block: 18823654
- Gas used: 221,430
- Confirmed within 2 seconds
Step 2: Check “Internal txns”

Now click the Internal txns tab. This is where the execution layer becomes visible.
You’ll see entries like:
- Delegate call → InfinityNameUpgradeable → 0.00032 ETH
- Call → session.cd → 0.00024 ETH
- Call → technicalakashcrypto.eth → 0.00004 ETH
- Call → 0x64…Da21 → 0.00004 ETH
The first line shows a delegate call with the full 0.00032 ETH context. This reflects the proxy contract delegating execution to its implementation contract.
The next three entries show how that 0.00032 ETH was actually distributed during execution, potentially representing protocol fees, referral distributions, rebates, or revenue allocation. The exact logic depends on the contract’s implementation. If you add those value transfers together, they total 0.00032 ETH.
This reveals something important. The ETH you sent was not transferred in a single simple movement. It was passed into delegated execution and then split across multiple internal calls.
Your wallet only showed that you sent 0.00032 ETH. The explorer shows how that ETH was actually routed.
Understanding Call vs Delegate Call
You’ll notice two types:
Call
A Call transfers control and optionally value to another contract or address.
In this case, the 0.00032 ETH was distributed across multiple internal calls.
This might represent:
- Protocol fees
- Treasury routing
- Service logic
Delegate Call
A Delegate call executes code from another contract while keeping the storage context of the calling contract.
This is common in proxy contract architectures. If you visit the contract page, you’ll see it labeled as a Proxy.

In simple terms:
- The proxy receives your transaction
- It delegates execution to an implementation contract
- Storage remains in the proxy
- This allows upgrades without changing the contract address
This pattern is common in modern smart contracts. Without the Internal txns tab, you would not see this architecture in action.
Internal Transactions vs Token Transfers vs Logs
It’s important to distinguish these:
Internal Transactions
Contract-triggered calls reconstructed from execution traces.
Token Transfers
Events emitted by ERC20 or ERC721 contracts.
Logs
Event emissions recorded in the transaction receipt.
Raw Trace
Opcode-level execution details.
Each reveals a different layer of the transaction. Together, they give you the full picture.

Why Internal Transactions Matter
Understanding internal transactions helps you:
1. Follow Value Distribution
See exactly where your assets went.
2. Detect Suspicious Behavior
Spot unexpected contract routing or hidden transfers.
3. Understand Proxy Architectures
See delegate calls and upgradeable contract patterns.
4. Analyze DeFi Transactions
In more complex DeFi swaps and bridge transactions, internal calls can include:
- Router interactions
- Liquidity pool updates
- Fee distribution
- Multi-hop swaps
What looks like “one swap” may involve dozens of internal executions.



