When using various Ethereum blockchain explorers like Etherscan to inspect addresses, you may come across certain addresses which have Transactions, Internal Transactions and Token Transfers. To understand the difference between them, we first have to understand the concept of external and internal addresses on Ethereum.
External and Internal Addresses
There are two types of addresses (accounts) in Ethereum: External and Internal.
When a user creates an address, that’s called an external address because it’s used for accessing the blockchain from the outside — from the “user world”.
When you deploy a smart contract to the Ethereum blockchain, an internal address is generated which is used as a pointer to a running blockchain program (a deployed smart contract). You can target it from the outside for calling functions, or you can target it from the inside so another deployed contract can call functions on an already deployed contract.
It’s important to note that all transactions on the Ethereum blockchain are set in motion from external accounts. Even if one smart contract is supposed to call another and that one in turn calls another, the very first transaction must be done by an external account. There’s currently no way to automatically call a transaction from the outside, though solutions are being worked on.
The key difference between external and internal accounts is the following:
External addresses have private keys and can be accessed by users. Internal addresses cannot be accessed directly as a wallet, and can only be used by calling their functions.
This brings us back to transaction types. Let’s inspect this address.
The address has several entries in the Transactions tab — some outgoing, some incoming. These transactions are external transactions — to and from external accounts. So as per the screenshot, we can see this address received 5 ether 7 days ago from this address and 0.2 ether 12 days ago from a Binance wallet. But if we look at the most recent sender, we’ll see some more interesting entries:
This address has been sending out Ether to individuals, but it did something else, too: it contributed to the EOS crowdsale and withdrew EOS tokens. Most of these transactions send 0 ether; they just call functions. For example, this transaction shows that almost half a year ago our protagonist called the
claim function on the EOS Crowdsale contract, and this resulted in the crowdsale sending that person 312 tokens in return.
The details of this transaction don’t matter much. We’re just looking at it to define the Transactions tab properly:
The Transactions tab lists all transactions initiated by external accounts, regardless of who initiated them — the receiver or the sender.
Now let’s look at the second tab of our first address: Internal Transactions.
Note: not all addresses will have this tab. It’s only present when an internal transaction actually happened on an account.
Let’s look at one of these — for example, this one.
This was a bid on the ENS (Ethereum Name Service) domain service, which allows entities to register an
eth domain like
bitfalls.eth so people can send ether straight to it rather than to a long and cryptic address like
0xbE2B28F870336B4eAA0aCc73cE02757fcC428dC9. The transaction describes itself as being sent to the
ENS-Registrar contract, which then transferred 0.94 ether to the address which initially formed the auction, and then the contract called the finalization function.
But how is this an internal transaction if it still needed to be initiated by a transaction from an external account? The original initiating TX was external, yes, but this particular transaction is just one in a chain of transactions that happened inside the blockchain, from contract to contract. As the contract automatically sent ether back due to being triggered by another contract (the ENS auction process), it was logged as an internal transaction because the transfer of ether was the result of logic that was built into the smart contract and was not sent by someone from the outside. Therefore:
The Internal Transactions tab lists all transactions initiated by internal accounts as a result of one or more preceding transactions.
Finally, there’s the Token Transfers tab.
Somewhat self-explanatory, token transfers are transactions that do only and exclusively that: transfer tokens. The token in question must be an ERC20 token (i.e. have standardized functions) and then it’ll be listed here if the only purpose of the transaction is to transfer tokens. Here we can see an example of a spam-token: 1500 BOBx tokens were sent to the address 8 days ago. Token spam (airdrop) is a common method of promoting an ICO project. Airdrops make recipients wonder where the tokens came from. As they Google for the project, its Google SERP rating grows and backlinks are created. Considering it’s almost free and very trivial to build your own token, the marketing costs for such a stunt are near zero. $10 to be more precise, which becomes obvious if we look at the transaction more closely …
We can see that it was indeed an airdrop with a lot of addresses targeted as recipients.
You’ll also notice that the tokens were sent “from”
0x00000.... So what does that mean? How can a null-address be the origin? This simply means that this one spam transaction was also the origin of the token. The token was created and distributed to 100 people in one fell swoop, for a mere $10. You can check how many addresses were part of this stunt by looking at Input Data.
You now know how to interpret the transaction types in Ethereum on Etherscan, and can with a reasonable degree of certainty say what was transferred to whom, when, and where from, as well as identify what triggered it. This will come in handy in your future explorations of the Ethereum blockchain.