Accounts & Wallets
An address with no code — an externally owned account — gets the entity page shaped around one question: whose money is this, where does it move, and how often. Smart accounts (Safe, ERC-4337, EIP-7702 delegated) get the same page plus what their code adds.
Key numbers
| Number | What it says |
|---|---|
| Balance | Native ETH, with its USD value at the live price |
| Direct transactions | Top-level transactions sent or received. Activity through internal calls, events or token transfers is deliberately not counted here |
| Nonce | How many transactions this account has sent, as the protocol counts them |
| State changes | How many times the account's own state — balance, nonce or code — changed |
| Fees paid | Total gas fees the account has paid as a sender, all time |
| Activity (30d) | A sparkline of the last 30 days, so a dormant wallet and a busy one differ at a glance |
Beside them, the liveness chip reads Active (any activity in the last year —
transactions, internal calls, events or token transfers) or Dormant. The
behaviour signals High traffic, Whale and New are described in
Addresses & Labels.
Portfolio
Token holdings and ETH, with the totals above them: what the tokens are worth, what the ETH is worth, and the sum. The counter under the token total — 246 of 325 tokens — is the honest part: it says how many of the held tokens could be priced, not how many are held. A token without a price is still in the list; it just cannot be added up.
The card carries its own at block # input. Reading the portfolio at a past
block is the same mechanism as the page-level ?atBlock=N
(reading an address at a past block),
and a past reading is shown in tokens and ETH without a dollar figure: the
dollars of that moment were the price of that hour, not today's.
Top counterparties
Who this address actually deals with, ranked by how often, never by how much value moved. The value question belongs to the Graph; this list answers "who does it keep meeting".
Each row carries:
- The kinds of row the pair meets in —
dir(direct transactions),tok(token transfers),nft— so you can tell a trading partner from a contract it merely calls. - Which side sent — for example "in 30 of them this address was the sender, in ≈1,919k the recipient" — with the note that one transaction can be both, so the two do not add up to the total.
- When they last met, and when they first ever met, with the block behind each date.
- How many interactions, and separately how many reverted. Reverted transactions are counted but never ranked as successes.
Above the list: the window (all time, 24h, 7d), the block the ranking was computed at, and how many counterparties exist in total — 20 of 16,301,939 is a top-20 view of a very long tail, not a complete list. The check address box answers the opposite question: does this specific address appear among the counterparties at all.
Large counts are approximate and marked ≈. Rows are ordered, not numbered:
hundreds of pairs can sit tied at the tail, and numbering them would invent a
precision the data does not have.
Validator withdrawals
An address that receives beacon-chain withdrawals gets a Withdrawals tab. It is not filed under Transactions, and the reason is protocol-level: a withdrawal has no transaction behind it — no hash, no sender, no gas. The consensus layer credits the balance directly.
The tab states the total withdrawn, how many credits arrived and from how many validators, and the period covered as both dates and a block range. Above the feed sits the registry snapshot — how many validators pay into this address, split by status (active, withdrawn, withdrawable, exited, queued to activate, awaiting deposit) as of a named epoch — and, when some of them are leaving, a line pointing at the network exit queue.
Each row is one credit: block, time, amount, and the validator index with its
public key. The index links to that validator's own page in TraceFast
(/validators/{index}).
Validators paying out here
An address that validators pay out to also gets a Validators paying out
here section on its Overview: the validators whose withdrawal credentials
point at this address, read from the validator registry as of a named epoch.
It counts them — total, active, withdrawn, slashed — states their combined
effective balance and the credential types (0x01 withdrawal address, 0x02
compounding), and lists the first of them by index, each linking to its
validator page.
Receiving the payouts does not make this address the validators' owner or operator, and the section says so. Where no validator pays out here, the section is absent; where the registry could not be read, it says that instead of showing zero.
Smart accounts
An account whose behaviour is contract code — a Safe, an ERC-4337 account, or
an EOA carrying an EIP-7702 delegation — reads as Smart account in the header
and keeps every panel above. What changes is the evidence: the chain facts name
the mechanism (delegated now, delegated before, modules installed, the entry
point it runs at), and Relationships names the code it delegates to. An
EIP-7702 delegation is reversible, so "was delegated" and "is delegated" are
two different facts and the page states them separately.
What an account does not get
No Holders and no Pools tabs: those are questions about an asset, and an account is not one. If you expected them, you are probably looking at a wallet that holds a token rather than at the token itself — open the token from the Portfolio.
Related pages
- Entity Page — the page all of this lives on
- Transaction feeds — everything under the Transactions tab
- Graph — value flow around the account
- Addresses & Labels — names, signals and confidence
- Validators — the queues behind the withdrawal side
Last updated 22 Oct 2026, 08:06 UTC · verified against TraceFast v1.0.261 · Markdown