Interpreting Event Log Data

In our previous article, “Understanding Blockchain Explorer Event Logs: A Deep Dive“, we explored the fundamental function of event logs in blockchain technology. We learned how these logs act as a continuous record of on-chain activity, providing invaluable insights into transactions, smart contract interactions, and network events. If you haven’t read it or don’t know much about the logic behind event logs, you are highly recommended to head over before delving deep in this article.

This article will guide you through the intricacies of interpreting event log data, empowering you to unlock the hidden stories within each log entry and gain a holistic view of blockchain activity. For those who haven’t yet explored the introductory concepts of event logs, we highly recommend checking out our first article before diving into the world of data interpretation.

The optimized event log functionality within a blockchain explorer empowers users with various functionalities. Let’s use Event 886 from the example data provided to illustrate this. Before decoding this particular event, let’s break down the labels in Event 886.

Event: This label specifies the type of event that occurred. In this case, it’s “Transfer”. This indicates that the event log is related to the transfer of some digital asset. Each decoded event includes event name (index_topic_n parameter_data_format parameter_data_name, etc.) Parameter_data_format is shown in green. Parameter_data_name is shown in red.

Address: This refers to the blockchain addresses involved in the event. There are typically two addresses: from and to. An address is like a unique bank account number on a blockchain network.

Topic: These are additional pieces of data associated with the event, specific to the type of event. In the case of a “Transfer” event, topics typically include the addresses of the sender and receiver,

• Topic 1: This usually represents the address the digital asset was sent from. Here, it’s represented in both hexadecimal (Hex) and decoded data (Dec) formats. The original Hex data is decoded with contract ABI once the contract is verified and its public ABIs are available. Dec data tends to be more readable.

• Topic 2: This usually represents the address the digital asset was sent to. Similar to Topic 1, it’s provided in both Hex and Dec formats.

Data: This section contains further details specific to the event. In this case, the data label is “amount”. It shows the amount of digital assets that were transferred. The value is provided in both Hex and Dec formats.

Additional data parameters in Event Logs: Beyond the core details explained earlier, event logs may include additional data depending on the specific blockchain platform and smart contract involved. Here’s a breakdown of some potential parameters you might encounter (these may not all be present in Event 886).

• Block number: This indicates the block number on the blockchain where the transaction containing the event log is stored. Each block acts like a page in the blockchain ledger.

• Transaction hash: This is a unique identifier for the entire transaction that includes the event log. You can use this hash to search for the complete transaction details on OKX Explorer.

• Block hash: This is the unique identifier for the block containing the transaction.

• Log index: This represents the position (like a line number) of the specific event log within the transaction. A single transaction can potentially contain multiple event logs.

• index_topic_1, index_topic_2, etc: These labels indicate the order (index) in which the topics are presented within the event log data. They simply clarify which topic corresponds to which address (e.g. index_topic_1 might be the “from” address and index_topic_2 might be the “to” address).

• uint256: This refers to the quantity of a digital asset involved in the transaction, represented using a specific data type called “uint256”. This stands for “unsigned integer 256 bit”. It’s a data type commonly used in blockchain development to represent very large non-negative whole numbers (without decimals). In the case of Event 886, “uint256 amount” indicates the number of UNI tokens transferred. As explained above, “unit256” is one of the data formats or called data types, whereas “amount” is the parameter name defined by this contract.

• Amount: This specifies the quantity of a digital asset being transferred in the event log.

What happened in Event 886?

Event 886 represents a transfer of digital assets on the Unisawp platform (as indicated by the “Uniswap. UNI token” label). Here’s a breakdown of what the event log suggests:

• An amount of 2,793,268,421,820,202,314,873 (Dec) UNI tokens was transferred. Note, this amount represents the exact number of UNI tokens transferred without any internal decimals, for data efficiency and accuracy reasons. Since UNI is an ERC-20 token which uses 18 decimals, this Dec amount is equivalent to approximately 2,793 UNI tokens. Both Dec (decoded) and Hex (original) data are essentially the same, just in different format, where Dec data tends to be more readable.

• The UNI tokens were sent from the address 0x26efc055aa99fd37c9c30c63e9eae4b63ab79502 (represented in both Hex and Dec).

• The UNI tokens were sent to the address 0x1d42064fc4beb5f8aaf85f4617ae8b3b5b8bd801 (represented in both Hex and Dec).