Event Logs

Event logs are a mechanism for smart contracts to emit structured data during their execution. They serve the purpose of providing a transparent and decentralized way for contracts to communicate information to external applications and other contracts.

Event logs are crucial for tracking specific activities, events, and changes within the blockchain. External applications can monitor these logs to react to specific events, extract relevant data, and update their own state. They are widely used for purposes like tracking token transfers, decentralized exchange activity, and more, enabling efficient communication and interaction on Ethereum.

Access the Event Logs by going to the transaction details page, and select the Logs tab:

Topic0

External applications can use Topic0 (among other topics) to filter and listen for specific events that are relevant to them on the Ethereum blockchain. It helps them identify which events are of interest and then extract relevant data from those events for further processing.

Topic0 is the first topic in the event log. It is often used to represent the event itself or some primary identifier for the event.

The Topic0 is essentially a Keccak256 hash of the event signature, composed of the event's name and its input parameters' types.

The event signature helps distinguish one event from another by ensuring that events with different names or parameter types have distinct signatures. When an event is emitted within a smart contract, its signature is used to create the event log, making it easier for external applications to search for and interpret specific events.

Event signatures are essential for contract developers and external applications that want to filter and interpret specific events on the Ethereum blockchain. They provide a standardized way to identify and differentiate events, enhancing the usability and transparency of decentralized applications.

{{img:etherscan}}Source: https://emn178.github.io/online-tools/keccak_256.html

{{img:bscscan,polygonscan,ftmscan}}Source: https://emn178.github.io/online-tools/keccak_256.html

Subsequent Topics

Developers can further specify which of these parameters should be used as topics by adding the indexed keyword to the parameter declaration. For example:

In this case, both sender and to are marked as indexed, meaning they will be used as topics in the event log.

Any parameters that are not marked as indexed will be included in the event log's data section. In the example above, amount0In, amount1In, amount0out, amount1out, are not marked as indexed, so they will be part of the event log's data.

In this case, both user and referrer are marked as indexed, meaning they will be used as topics in the event log.

Any parameters that are not marked as indexed will be included in the event log's data section. In the example above, level and place, are not marked as indexed, so they will be part of the event log's data.

The decision of which parameters to mark as indexed depends on the use case and how the contract developer intends the event to be used by external applications. Typically, parameters that are used for filtering and quick identification of events are marked as indexed, while parameters that provide additional data or context are left in the data section.

Pro Tip: Filter for an Event Log emitted by a contract

Visit the Logs tab on the Transaction Details page, click the magnifying glass icon to filter for a specific contract event, and use additional filter fields to refine your search.