EventSpec: Defining and Detecting Event-Semantic Issues in Blockchain Ecosystems

1 Introduction

• The EVM does not enforce log semantics, and a cross-application taxonomy and detection methodology remain missing despite prior domain-specific studies.Unchecked misleading logs can trigger asset theft, fraud, and interoperability failures when off-chain systems treat them as authoritative.Source: §1 · p. 2
• EventSpec infers event-emission specifications from contract-corpus behavior and uses explainable differential checking to flag target-contract deviations.Its specifications capture event layout and semantic constraints, with symbolic equality checks for event-collision anomalies.Source: §1 · p. 2
• 90.17% overall comprehensive precision across 6,617 real-world contracts; the harness reproduced two attack vectors and identified issues across relayers, explorers, wallets, and NFT marketplaces.The reported precision is based on manually labeled results.Source: §1 · pp. 2–3
• The study defines five event-semantic defect types and two off-chain attack vectors from incident reports and audit findings.The taxonomy is based on open card sorting.Source: §1 · p. 2

2.1 Smart Contract Events and Transaction Logs in EVM-Based Blockchains

• Each log records its emitting address, topics, and data; non-anonymous event signatures occupy topic0, while indexed parameters use later topics and non-indexed parameters use data.Logs are emitted by LOG0–LOG4 opcodes and are not part of contract state; off-chain systems must validate emitters and relevant state transitions when correctness or security requires it.Source: §2.1 · p. 3

2.2 Token Standards

• ERC-20 and ERC-721 define events such as Transfer and Approval that external systems use to monitor token activity and update balances or ownership records.Source: §2.2 · p. 3

2.3 Off-Chain Modules

• Bridge relayers monitor source-chain logs to trigger destination-chain actions, but listeners that skip emitter or state validation expose an attack surface.Such assumptions can improve performance, while leaving misleading events able to trigger incorrect off-chain actions.Source: §2.3 · pp. 3–4

3.2.1 Manual Filtering.

• Filtering retained 1,020 audit reports, 1,294 findings, and 11 incidents; eight incidents caused about $115.6M in direct losses.The researchers excluded findings unrelated to event semantics and retained all severity levels; relevance screening agreement was κ=0.89.Source: §3.2.1 · pp. 4–5

3.2.2 Open Card Sorting.

• Two-round open card sorting achieved κ=0.95 on the independently analyzed subset, and Event Emission Mismatch accounted for about 85% of retained findings.Two researchers first jointly analyzed a random 40% sample, then independently categorized the remaining 60%; experts reviewed the resulting taxonomy.Source: §3.2.2 · p. 5, §3.3 · pp. 5–6

3.3 Event-Semantic Issues in Smart Contracts

• The taxonomy distinguishes event collision, state–event mismatch, unauthorized event emission, event emission mismatch, and event parameter mismatch.Three independent experts endorsed the five categories as meaningful, mutually exclusive, and exhaustive, identifying no missing class.Source: §3.3 · pp. 5–6

3.3.1 Event Collision (EC).

• Event collision occurs when distinct execution paths emit the same signature with overlapping parameter domains, making the event’s origin ambiguous.In the example, an unchecked deposit path can emit a Deposit log without transferring ETH, which bridge validators may accept as a genuine deposit.Source: §3.3.1 · p. 6

3.3.2 State-Event Mismatch (SEM).

• State–Event Mismatch occurs when an event conflicts with the state transition it claims to summarize, such as a Transfer log without balance updates.Off-chain systems relying on that log may record a transfer that did not occur on-chain.Source: §3.3.2 · p. 6

3.3.3 Unauthorized Event Emission (UEM).

• Unauthorized event emission lets untrusted callers emit privileged events when access controls are missing, insufficient, or checked too late.The DeFi Saver example involved an unrestricted logging function that could mislead off-chain monitors.Source: §3.3.3 · p. 6

3.3.4 Event Emission Mismatch (EEM).

• Event Emission Mismatch concerns wrong, missing, extra, miscounted, or misordered events, while Event Parameter Mismatch concerns incorrect parameters in an otherwise expected event.Examples include emitting Deposit instead of Withdraw and swapping Transfer’s from and to fields, which inverts the reported transfer direction.Source: §3.3.4 · p. 7, §3.3.5 · p. 7

3.4 Off-Chain Attack Vectors

• Event Origin Confusion accepts logs from an unintended emitter, while the second vector infers behavior from events without checking on-chain state or storage updates.The examples include pNetwork validators accepting an unintended contract’s events and marketplaces consuming forged NFT transfer events without ownership changes.Source: §3.4.1 · p. 8

4.1 Overview

• The Extract, Infer, and Diff modules capture log-site observations, aggregate them into event and function profiles, and compare target observations with those profiles.Findings link back to profiles and concrete log- and function-level evidence.Source: §4.1 · p. 9

4.2 Notation and Schema

• An event specification combines layout, emission behavior, and semantic constraints, with support and confidence statistics for confidence-gated checking.Constraints include parameter origins, guard predicates, and expected state-write bindings.Source: §4.2 · p. 9
• Each log observation records its event signature, operand profiles, guards, reachable state writes, and operand–state binding evidence for comparison with an inferred event profile.The inferred profile aggregates the same fields, and each log site is checked against the profile matching its event signature.Source: §4.2 · p. 9

4.3.1 Log-Site Analysis and Operand Tracing.

• EventSpec analyzes only statements that can reach a log site, tracing each operand’s dependencies backward to derive an opcode footprint without full path exploration.Calldata, environment values, and memory or storage reads are treated as taint sources.Source: §4.3.1 · pp. 9–10
• Dominator blocks provide mandatory guard evidence because they execute on every path to the log site; their predicates are mapped to guard categories.The log-site CFG slice and dominator-based guard inference are illustrated in Figure 9.Source: §4.3.1 · pp. 10–11, Figure 9 · p. 10

4.3.2 Operand Reconstruction and Profiles.

• Non-indexed operands are reconstructed from MSTORE writes and aligned data slots, while guard attribution can traverse callers and state bindings connect operands to reachable storage reads or writes.These contextual signals support guard validation, state–event consistency checks, and event-collision detection.Source: §4.3.2 · p. 11, §4.3.3 · p. 11

4.4.1 Function Clustering.

• Functions are clustered by a behavioral signature combining guard categories, storage-write kinds, operand dependency and source kinds, modal log shape, and frequent opcodes.Functions sharing the signature form a cluster.Source: §4.4.1 · p. 11

4.4.2 Event Expectations and Shape Profiles.

• Cluster profiles estimate event-emission probabilities and log-count distributions, while event-shape profiles capture topic and data counts and indexed-label expectations.Deviations from the dominant shape are treated as potential parameter mismatches.Source: §4.4.2 · pp. 11–12
• Only the top-k event profiles by support are retained, and differential checking enforces minimum support; smoothing stabilizes similarity scores for limited-support profiles.The smoothing also prevents a single missing label from collapsing the overall score.Source: §4.4.2 · p. 12, §4.4.4 · p. 12

4.5 Differential Checking

• Differential checking matches target events and functions to inferred profiles, scores feature similarity, and applies minimum-similarity, support, and Wilson-interval gates before recording findings.Target-only checks cover missing logs, event collisions, and insufficient guards.Source: §4.5 · p. 12

4.5.1 Profile Matching and Similarity.

• Event similarity combines indexed-label and parameter-count likelihoods with operand-source, operand-dependency, storage-write, and guard-category overlap.Operand distributions use Jensen-Shannon similarity, while storage-write and guard overlap use Jaccard similarity.Source: §4.5.1 · p. 12

4.5.2 Confidence Gating and Thresholds.

• Probability-based decisions require a sufficiently narrow Wilson interval, alongside minimum similarity and support thresholds; guard, storage, and operand-profile checks also have thresholds.Figure 10 illustrates missing guard evidence triggering an Unauthorized Event Emission finding when the emitting function has an empty guard summary.Source: §4.5.2 · p. 12, Figure 10 · p. 13, §4.5.3 · p. 13

4.5.3 Findings.

• The taxonomy rules flag overlapping operand constraints, changed operand–state bindings, absent guard evidence, emission-count deviations, and layout or operand-profile inconsistencies.The categories are Event Collision, State–Event Mismatch, Unauthorized Event Emission, Event Emission Mismatch, and Event Parameter Mismatch.Source: §4.5.3 · p. 13, Table 2 · p. 13

4.6 Off-Chain Evaluation Harness

• The harness is an evaluation component, not part of EventSpec’s static-analysis pipeline.It tests whether off-chain consumers accept misleading event semantics that contracts can legitimately emit.Source: §4.6 · p. 14
• EOCA tests whether a consumer accepts a forged event from an attacker-controlled emitter alongside a genuine event from the target.An allowlist based only on event type can accept the forged event when it does not bind events to their intended emitters.Source: §4.6 · p. 14
• ESDA tests whether a consumer records a state change from an event emitted without the corresponding on-chain update.The example is a Transfer event without a balance change, producing a sleepminting pattern when the consumer does not cross-check state.Source: §4.6 · p. 14

5.1 Research Questions

• The evaluation asks about ERC consistency, detection accuracy and prevalence, and the feasibility of two off-chain attack vectors.EventSpec was implemented using Gigahorse for bytecode decompilation and CFG construction; the remaining extraction, inference, and checking components comprise about 7,000 lines of Python.Source: §5.1 · p. 14

5.2 Datasets

• The target pool comprised 6,617 verified Ethereum contracts, and effectiveness was evaluated on a random 95-contract labeled subset.The corpus for behavior inference contained 212,072 contracts after bytecode deduplication and exclusion of contracts exceeding the decompilation timeout.Source: §5.2 · pp. 14–15

5.3 RQ1: ERC Consistency of Inferred Specifications

• ERC specification agreement was stable across smoothing settings, while top-k=1 reduced layout matches by pruning lower-support compliant modes.The authors attribute semantic disagreements partly to ERC guard and state-update requirements that their inferred guard types do not capture, and use α=1, minimum support 20, and top-k=3 for RQ2.Source: §5.3 · p. 16

5.4 RQ2: Detection Accuracy and Prevalence

• 90.17% comprehensive precision and 96.11% macro-average recall were reported on the manually labeled evaluation.Table 5 summarizes large-scale detection yield on 6,617 contracts and effectiveness on 95 labeled contracts, with five additional Event Collision cases used for that category.Source: §5.4 · pp. 16–17, Table 5 · p. 17
• Event Emission Mismatch appeared in 98.44% of the target pool, followed by State-Event Mismatch at 62.85% and Event Parameter Mismatch at 55.37%.The authors caution that the 98.44% figure reflects the detector’s operational definition, not independently confirmed exploitable vulnerabilities in that share of contracts.Source: §5.4 · p. 17
• Mythril, SmartCheck, and Oyente had 0% F1 across all five categories; Slither covered only narrow subcases and missed several defect patterns.Slither’s SEM precision and recall were 17.74% and 24.44%; its EEM precision was 100.00% and recall was 52.75%.Source: Table 6 · p. 18, §5.4 · p. 18

5.5 Real-World Attack Feasibility (RQ3)

• The harness reproduced emitter confusion in bridge relayers and event-state desynchronization affecting explorers, wallets, and NFT marketplaces.Six wallet issues were reported, four confirmed, including a $600 bounty; two remained pending. The on-chain audit also found unauthorized event emission in three DeFi projects and one GameFi project.Source: §5.5 · pp. 18–19

5.6 Threats to Validity

• Results may not generalize to inactive or highly specialized contracts, and detection accuracy is bounded by decompilation failures and solver or time limits.The study also notes that public incident reports and audit findings may underrepresent rare or undocumented issues.Source: §5.6 · p. 19

6.1 Smart Contract Security Analysis

• General-purpose smart-contract analyzers target vulnerability templates or user-supplied properties rather than event semantics.Event-semantic checking needs a reference for emitter, timing, and parameter–state consistency; EventSpec infers profiles from bytecode, including for non-ERC events without written specifications.Source: §6.1 · p. 20

6.2 Smart Contract Events

• Prior work examines event usage, cross-chain security, token tracking, sleepminting, and documentation mismatches in particular domains.This work offers a cross-domain taxonomy and recurring off-chain attack vectors covering emitter and state–event consistency.Source: §6.2 · p. 20

7 Discussion and Mitigation

• Contracts should emit events after state updates, guard privileged emissions, avoid ambiguous signature reuse, and keep parameters consistent with the ABI.The authors also recommend validating ambiguous inputs and the ordering and indexing of parameters.Source: §7 · p. 20
• Off-chain consumers should validate emitters, signatures, topics, parameter types, reverted status, and state or call context for high-risk operations.They should bind each event to its intended call, validate the full sequence, and monitor logs against state invariants and versioned schemas.Source: §7 · p. 20
• 900 ms was the median trace latency across 26 transactions; the slowest trace used 60% of Ethereum’s 12-second block budget.The average was 1,381 ms, P95 was 3,030 ms, and maximum was 7,238 ms; a local archive node can remove network round trips.Source: §7 · p. 20

• 90.17% comprehensive precision was achieved across 6,617 contracts and labeled data.Source: §8 · p. 20
• The off-chain harness reproduced both attack vectors and confirmed issues in relayers, explorers, wallets, and NFT marketplaces.Source: §8 · p. 20
• EventSpec uses corpus-inferred event and function profiles with explainable differential checking; the paper defines five defect types and two attack vectors and provides mitigations for contracts and off-chain consumers.Source: §8 · p. 20