Back to Foundry

Address event parameters should be indexed

crates/lint/docs/event-fields.md

1.8.11.6 KB
Original Source

Address event parameters should be indexed

Severity: Info ID: event-fields

Flags events whose address parameters are not declared indexed.

What it does

For each event, identifies unindexed address parameters and reports a single warning listing them. The lint respects the EVM cap on indexed parameters (3 for normal events, 4 for anonymous) and does not flag events that are already at capacity. Events that already have at least one indexed parameter are left alone: the author has clearly chosen what to index, so we stay silent.

Why is this bad?

Indexed event parameters are stored as topics in the transaction log, which lets off-chain indexers, explorers, and clients efficiently filter events by sender or recipient. Leaving filterable fields unindexed forces consumers to scan and decode every event, which is slow and brittle.

Example

Bad

solidity
event Transfer(address from, address to, uint256 value);
event Mint(address to, uint256 tokenId);

Good

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

Limitations

This lint is intentionally conservative:

  • Only explicit address parameters are checked. address payable, custom types, interfaces, and user-defined value types are not unwrapped.
  • Only actionable suggestions are reported. If an event has no remaining indexed slots (3 for normal events, 4 for anonymous), no warning is emitted. If only some slots remain, only the first parameters that could still be indexed are reported; already-indexed parameters are never suggested for change.