Transaction feeds
Transactions on an entity page is a group, not a single
list. It opens on the transaction feed and holds everything a transaction did:
the transfers it carried, the calls it made, the slots it wrote, the logs it
emitted. Each feed is addressable — ?tab=transfers, ?tab=internal and so on
— and each pages with Older / Newer rather than page numbers, because a
live feed shifts under a numbered page.
Rows of the token, NFT and internal transfer feeds and of the Events feed carry a star: a signed-in reader can save that one row to Favorites.
Transactions
The top-level feed: every transaction where this address is the sender or the recipient.
- Filters — direction (All / Sent / Received), status (All / Success / Failed), whether the transaction carried token transfers, and — where the address moves ETH — a minimum ETH value.
- Method breakdown — the methods this address actually sees, each with its
count:
transfer 103M,approve 13.8M,transferFrom 5.2M,transferWithAuthorization 295.5K,permit,mint… Selecting one filters the feed. There is also a counterparty box to pin the feed to one address. - Columns — tx hash, time, to/from (labeled), method, Inside, fee, value.
The Inside column is what makes the feed more than a list of hashes: per row it shows what happened within that transaction — transfers carried, internal calls, state and storage writes, logs emitted — so you can see which rows are worth opening before opening them.
Token Transfers
Fungible movements: ERC-20, plus ERC-777 and ERC-4626 behind their own chips, each chip carrying the count for this address. Direction (All / Sent / Received) and a date, counterparty or block-range narrowing sit beside them.
Columns: transaction, time, counterparty (labeled), token standard, token, and the value with its USD equivalent where a price exists.
:::info A feed that refuses rather than lies
On an address with an enormous history, filtering across all of it is not attempted. Instead of showing a partial result that looks complete, the feed says it was not read at all — "nothing below is a statement about this address" — and tells you what would make the question answerable: narrow to a block or date range of about a week (≈50,400 blocks).
A silent partial answer is the failure mode this replaces: it would look exactly like a complete one. :::
NFT Transfers
ERC-721 and ERC-1155 movements, kept in their own feed because a token id is not an amount. Each row names the event, the sender and recipient (labeled where known), and the token id; for ERC-1155 it also says how many copies moved. Sorting is newest or oldest first, with a Clear all for the filters.
Internal
Internal transfers are ETH moved by nested calls inside a transaction —
CALL, CALLCODE, CREATE, CREATE2, SELFDESTRUCT, each available as a
filter alongside direction. Columns: transaction hash, time, call type,
counterparty, the in transaction pair showing which two addresses the frame
actually connected, and the value with its USD equivalent.
When there is nothing to show, the empty state explains the distinction rather than leaving you guessing: ETH sent straight to the address arrives as the transaction itself and belongs in the Transactions feed.
State Changes
Account-level changes per block: balance, nonce and code, filterable by which of them changed (and by the block the account was created in). Columns: block, time, balance delta, balance after, nonce, and what changed.
Individual storage slots are not here — they are in Storage, and the feed says so at the top. The two are different subjects: this is the account, Storage is the contract's own state.
Storage and Events
Both are covered in Contracts: Storage shows who writes the contract's slots and how their values change, Events lists the decoded log it emitted. Events appears only where the address has ever carried code; Storage also stays where the code is gone but a storage history remains.
Deployments
The contracts this address created: the contract, the block, the deploy opcode
(CREATE or CREATE2), the deploying transaction, whether its deploy-time
bytecode is shared with another contract on the page or unique, and
whether it is an EIP-1167 minimal proxy. A bytecode cell opens the cluster of
contracts with the same code. A summary above the table covers the deployer's
whole history; a Since block filter narrows the list.
A creation that ran inside a call that reverted is listed with a Reverted badge: the deploy happened inside the transaction and was rolled back, so no contract was left at that address by it.
The tab states how much of the history it can list, because "never deployed" and "cannot list them yet" are different answers:
- All 12 deployed contracts are listed. — the list is complete.
- 40 of 112 deployed contracts listed — the rest are not available from the deployment index yet. — a partial list, named as partial.
- The deployer summary counts N deployed contracts, and the deployment index cannot list them yet. — an empty table that is a gap in coverage, not an empty history.
- No contract deployments observed for this address. — the tab's word for "none".
Filtering by block and older pages need a sign-in.
DEX Trades
Swaps involving this address, across protocols: time, transaction, the pool (labeled with its protocol and fee tier) and the swap itself, written as what left and what arrived. Where the address is always on one side, the feed says so above the table — for example "this address is the recipient on every trade below" — instead of leaving the direction to be inferred.
On an ordinary address this is its own trading; on a pool it is the trading that happened inside it.
Related pages
- Entity Page — tabs, header and URL parameters
- Accounts & Wallets — portfolio, counterparties, withdrawals
- Contracts — storage and events in full
- Smart Contracts — deployers and bytecode families
- Transactions — where a feed row leads
Last updated 22 Oct 2026, 08:06 UTC · verified against TraceFast v1.0.261 · Markdown