Contracts
Open the contract explorer in TraceFast →
A contract's entity page answers two different questions in two different places: what this contract is (chain facts and relationships), and what it has done (storage, events and the rest of the feeds).
What it is
The Chain facts card groups the proven statements:
| Group | What it covers |
|---|---|
| Nature | Carries code now, has ever carried code, was destroyed, was redeployed, is a precompile or a system contract |
| Architecture | Proxy and which family (storage slot, beacon, EIP-1167 clone, Safe), whether the implementation slot is mutable, whether it is itself an implementation, a beacon or a proxy admin, or immutable |
| Interfaces | The ERC interfaces the executing code presents — ERC-20, 721, 1155, 4626, 1271, 2981, 165 |
| Capabilities | Privileged surfaces present in the code — mint, pause, blacklist, emergency withdraw — and, separately, the ones actually observed being used: an upgrade performed, a pause that happened, ownership renounced |
| Asset | What kind of token it is, if it is one — see Tokens & Collections |
| Derived | Folded verdicts over the above: account type, lifecycle, proxy kind, control model, upgrade authority |
Two rules make the card readable. A fact appears only when it was proven — absence is not a "no". And a fact claims exactly what it says: Pause function means a pause-family function exists in the code that executes, not that the contract is paused now, and not who may pause it.
Relationships
The structural links, read from both ends:
- Deployed by — the account that executed the
CREATE, with the deploying transaction and block. Where the lineage was never captured — pre-Byzantium deployments, externally created code — the row says so rather than guessing. - Implementation — what a proxy delegates to right now.
- Implementations before — every implementation it has stood on, as block intervals. An interval with no end was still open at the edge of coverage.
- Used by proxies — on an implementation contract, the proxies that have delegated to it. A sample, not a count — the page says so instead of implying completeness.
- Delegated to by — accounts pointing at this code with an EIP-7702 delegation.
- Same bytecode — how many contracts run byte-identical runtime code. The
cluster itself lives at
/bytecodes/{codeHash}. - Impersonates — for a lookalike contract, what it imitates.
Storage
Storage answers who writes this contract's state. The header counts total
writes, unique slots touched, distinct callers and executors, the share of
writes that arrived through DELEGATECALL, the deepest call that reached it,
and the block range over which all of that was observed. A daily storage
activity chart sits under them.
Counts marked ≈ are estimates. Writes counts every SSTORE, including
writes that put back the value already there — it is not the number of times a
value changed; that is counted separately below. Two badges sum the shape up:
Proxy Storage when part of the writes arrive through DELEGATECALL, and
Deep DeFi when calls deeper than five levels reach it.
Who writes here ranks the callers: the caller, the executor (the code that
actually ran — for a proxy, the implementation), how many writes, how many
transactions, and the block range of their activity. On a proxy this table is
the clearest picture of a protocol's real users, because the executor column
keeps proxy and implementation apart instead of merging them. Two tables follow
it: Deep Call Analysis — writes from call stacks deeper than five levels,
by executor, with the maximum and average depth — and, on a proxy,
Implementation Writers — the implementations that wrote to its storage
through DELEGATECALL.
How values change
Writing a slot and changing its value are different counts. Value Changes counts the times a slot's value changed at a block boundary: several writes of one slot in one block are one change, and a write that put back the same value is none. ≈ Slots Changed Value counts the distinct slots whose value ever changed.
- What changes now — the slots that changed most over the last day or the
last week, with how many changes and the last one. A slot is named as a
variable where its key is known:
slot 9 [Uniswap V4: PoolManager]is entry of mapping slot 9 for that address. History opens the slot's change history, one row per block, with the value before and after each change; the order of writes inside a transaction is on that transaction's State tab. - Parameters & references — the contract's plain slots (declared variables and packed fields) with their current value, by slot or by most recent change, shown as hex, a number or an address. Their names are not known without the contract's source. A slot set once and never again is usually a setting or an address the contract points at; a rarely changed slot with a recent change is a change of configuration.
- Who reads, who writes — per day, the transactions that wrote to the contract's storage and those that only read it. A contract many transactions only read is one others depend on — the pattern of oracles, registries and pools used for quotes.
Where a value is not stated — not stored for that stretch of history, wiped by a self-destruct, or rewritten by the protocol at the end of the block — the page names the reason. It is never shown as a zero.
Storage outlives the code
A contract destroyed before Cancun, or an account whose EIP-7702 delegation was cleared, has no code today and still a history of writes. The Storage tab stays for it, with a line that the code is gone and the storage history is kept. For an investigation of a one-shot or self-destructed contract this is often the most valuable part left.
Events
The log this contract itself emitted: block, transaction, log index, event
name, and a decoded summary where the ABI is known — Transfer 0xdd52… → 0x3b4d… 31,670 USDC rather than raw topics. Undecoded logs are still listed;
they simply keep their raw shape instead of a guessed name.
Accounts and storage are different questions
State Changes counts changes to the account — balance, nonce, code.
Storage is about individual slots inside the contract. A busy contract can
show State changes 1 while its storage carries hundreds of millions of
writes: the account itself only ever changed when the code was deployed.
Destroyed and redeployed contracts
A contract that has been self-destructed keeps its page and its history: the
nature facts say it held code and that the address is codeless now, and the
timeline still shows what happened. Where code was deployed to the same address
more than once, that is its own fact (redeployed), because the address is
continuous while the code behind it is not.
Related pages
- Entity Page — the page all of this lives on
- Smart Contracts — the deployed-contract inventory
- Transaction feeds — the calls, transfers and writes in detail
- Storage Analytics — storage across the whole network
- Address attribute dictionary — these facts over the API
Last updated 22 Oct 2026, 08:06 UTC · verified against TraceFast v1.0.261 · Markdown