Chapter 5 · Solidity foundations · lesson 9

Events and logs

8 min

A contract cannot call your frontend. It cannot send you an email, hit a webhook, or push a notification. The only way anything outside the chain learns that something happened is events.

Ledger.solRepair

Loading editor…

The event is declared but never fired. Fix that.

Run the code to see what happens.

Nudge

Declaring an event does nothing on its own. Something has to fire it.

Show me the approach

The keyword is `emit`, and it goes after the state change.

Show me the code

Add `emit Deposited(msg.sender, amount);` as the last line of `deposit`.

Explain the solution

Order matters more than it looks: emit after the state change, so the log reflects what actually happened. Events are also how every frontend and block explorer learns anything happened — a contract with no events is invisible.

Where logs live

Events are written to a separate part of the block called the log. Crucially, contracts cannot read logs — not their own, not anyone else's.

That restriction is why logs are cheap. Storage costs 20,000 gas because every node must keep it available for execution forever. A log costs a few hundred because no contract will ever need to read it — nodes can prune it, and light clients can skip it.

Logs are for the outside world. Storage is for the contract.

indexed, and why it matters

event Transfer(address indexed from, address indexed to, uint256 value);

Up to three parameters can be indexed. Those become topics — searchable fields. Everything else is packed into the data blob.

"Show me every transfer to this address" is instant if to is indexed, and requires scanning every log ever emitted if it is not. Which parameters you index determines what your dApp can efficiently ask.

Predict

A block explorer shows a token's full transfer history. Where does it get that from?

It reads the token contract's storageIt indexes Transfer events from every blockIt replays every transaction from genesis

What to emit

Emit on every meaningful state change: deposits, withdrawals, transfers, ownership changes, configuration updates.

Two rules worth keeping:

Emit after the state change, so the log describes what actually happened.
Never put anything secret in an event. Logs are as public as storage.

Check

Can a contract read an event it emitted earlier?

Yes, using the log indexNo — logs are write-only from the EVM's point of viewOnly events it emitted in the same transaction

Worth remembering

Events are the only way a contract communicates with the outside world.
Logs are write-only from inside the EVM — contracts can never read them, which is why they're cheap.
Up to three parameters can be `indexed`, becoming searchable topics.
Transaction history lives in logs, not storage; storage only holds the current value.
Emit after the state change, and never log anything you wouldn't publish.