Detect Redundant Soroban Events

[mijinummi]

🧠 Concept

Detect duplicate event emissions within the same execution path.

⚠️ Problem

Repeated events can increase resource consumption without providing additional information.

📁 Implementation Scope

• packages/rules/soroban/events/
• packages/analyzers/soroban/events/

✅ Requirements

• Track emitted events
• Compare topics and payloads
• Detect duplicate emissions
• Suggest safe consolidation

🎯 Acceptance Criteria

• Duplicate events detected
• Event payloads compared
• Safe suggestions generated
• Tests added

[glendell03]

I'd like to work on this. Based on the scope described, I'd implement the detector under packages/analyzers/soroban/events/ to walk each execution path, record env.events().publish(topics, data) call sites in order, and flag calls where topics and payload are structurally equal (or a strict subset) to a prior emission with no state mutation in between. The corresponding rule under packages/rules/soroban/events/ would report the duplicate site and suggest either hoisting the event out of a loop/branch or removing the redundant call.

One design question worth agreeing on first: how strict should the "duplicate" comparison be — exact topic+payload equality only, or also flag cases where payload differs but topics match and the emission is clearly redundant (e.g., inside a loop with unchanged state)? I'd lean toward starting with exact equality to avoid false positives, then extending. I'd also add path-sensitivity tests (loops, branches, early returns) as part of the test suite requirement.

Happy to take this if it's unassigned.