What is event log?

A record a contract writes during execution to announce that something happened, cheaper to store than state and readable by outside software but not by contracts themselves.

Standards define the events every compliant token emits, which is how a wallet can display transfers of a token it has never seen before (source: EIP-20). Logs carry indexed fields that let an indexer filter them efficiently. Anything a contract does not emit cannot be reconstructed from logs, which is a common reason two tools report different histories for the same address.

Logs are not part of the state a contract can read, so no contract can react to another's event without an outside actor relaying it back in. That asymmetry is deliberate: logs are an output channel for humans and servers, not an input channel for code.

How it works

When a contract executes, it can write a log entry consisting of the emitting contract's address, up to four indexed topics, and an arbitrary block of unindexed data (source: the Ethereum Yellow Paper). For a normal event the first topic is a hash of the event's signature, which leaves three slots for indexed parameters.

Indexed topics are what make logs searchable. A node can answer "every transfer where the recipient was this address" by filtering on topics without replaying any execution, which is how a block explorer builds an address history in milliseconds.

Logs are stored in the transaction receipt rather than in contract storage, and they are much cheaper to write than state. That price difference is why contracts announce far more than they store.

The limits matter. A contract cannot read a log, its own or anyone else's. A log only exists if the contract's author chose to emit it, so a token that skips the standard transfer event is invisible to most tooling even though its balances are perfectly correct. And a light client cannot verify a log without the receipt data behind it.

Example

Illustrative case. You receive a token and your wallet shows it immediately, with the right amount and symbol, despite never having heard of that contract. What happened is that the wallet's data provider filtered logs for the standard transfer event with your address in an indexed topic, then read the contract's decimals and symbol to format it. Nothing about your balance was queried directly. If the token had not emitted a standard transfer event, your balance would be correct on chain and absent from the interface.

Why it matters when you buy

Tax tools, portfolio trackers, and explorers all reconstruct your history from logs, so an asset that emits nonstandard events shows up wrong or not at all in every one of them. When records matter, reconcile a tracker's output against the exchange's own statements and see the tax pages.

Related terms

transaction receipt — where logs are stored, indexer — what reads them at scale, subgraph — a common way to query them, block explorer — the interface built on them, erc 20 — the standard defining transfer events, smart contract — what emits them.

Questions

Why does my portfolio tracker show a different history than the explorer?

Because each reconstructs history from the events it chose to index. A tool that ignores an unusual event, or a token that emits a nonstandard one, produces a gap that looks like a missing transaction.

Can a contract be notified when another contract emits an event?

No. Logs cannot be read from inside the virtual machine. Reacting to an event requires an off-chain watcher that submits a new transaction, which is what keepers and oracle services do.

Are logs permanent?

They are part of the chain's history and can be recomputed by replaying blocks, but nodes are not obliged to keep receipt data indefinitely. Long-range historical queries generally need an archive node or a service that keeps its own index.