Events and Logs: Where Most Contract Data Actually Lives

When you look up a token transfer on an explorer, you are usually reading an event rather than contract state.

What events are

A contract can emit a log entry during execution. The entry is recorded in the transaction receipt and stored by nodes, and it is not part of state.

Crucially, contracts cannot read their own events. Events exist for external observers only.

Why they are used

Storage is expensive and permanent. Events are considerably cheaper because they do not need to be held in the state that every node must keep available for validation.

So anything that needs to be visible to users, explorers and applications, but not to contract logic, is emitted as an event.

Token transfers are the canonical example. The balance mapping is in state, and the record of each individual transfer is an event.

What this explains

Why explorers show transfer histories. They index events.

Why a contract cannot tell you its own history. It cannot read its own logs.

Why some data is hard to query. If something was only ever emitted as an event, retrieving it requires scanning logs across blocks, which is what indexing services do.

Why applications depend on indexers. Reconstructing application state from events is the standard architecture, and it is why an indexer outage makes an application appear broken while the chain is fine.

The structure

Events have indexed and non-indexed parameters. Indexed ones can be filtered efficiently; non-indexed ones are in the data payload and require decoding.

A contract’s ABI describes how to decode them. Without it, an event is an opaque blob, which is why unverified contracts produce unreadable activity on explorers.

The practical use

Verifying what a transaction did. The token transfers section of an explorer’s transaction page is built from events, and it is the authoritative record of what moved.

Checking a swap. Compare the events against what the interface quoted. This is how you establish what you actually received.

Auditing approvals. Approval events show what permissions were granted and when.

The reliability note

Events are consensus data. They are as authoritative as anything else in a receipt.

What is not authoritative is the interpretation an explorer layers on top: labels, token identification and price conversion. The event says an amount of a token at a contract address moved between two addresses. Everything else is annotation.

That distinction is the same one that applies throughout this subject, and it is worth holding onto when reading any derived data, including exchange balance estimates built from address clustering rather than from the figures venues such as exchanges that let you specify the network publish themselves.