Standardize structured event emission across all contracts

[Meshmulla]

Summary

Off-chain consumers (the Swipely backend and dashboard) rely on contract events to track bridge activity, but event emission looks inconsistent across modules. Standardizing event topics and payloads makes indexing far more reliable and future-proof.

What we'd like

• Define a shared convention for event topics and data shapes (naming, versioning, indexed fields)
• Audit each contract that changes state and ensure it emits a well-formed event
• Document the full event catalog so downstream indexers know exactly what to expect

Where to look

• soroban/src/event_query.rs — existing event querying
• soroban/src/alert_system.rs, escrow_contract.rs, operator_rotation.rs, governance.rs — key state transitions that should emit events
• soroban/docs/ — where the event catalog doc should live

Acceptance criteria

• A documented event-topic convention exists (with a version field)
• Core state-changing functions emit standardized events
• An EVENTS.md catalog lists every event, its topics, and payload
• Tests assert the expected events are published for key flows

Notes

Coordinate the payload shapes with whoever owns backend indexing so we only define this once.

[jrcity]

I would like to contribute to standardizing event emission across the Soroban contracts to provide a consistent and reliable interface for off-chain consumers such as the Swipely backend and dashboard.

From the issue description, the primary challenge is ensuring that all state-changing contracts emit events following a single, well-defined convention. Consistent event topics and payloads are critical for reliable indexing, analytics, monitoring, and future integrations. My approach will begin with an audit of the existing event implementation to identify inconsistencies across modules before defining a shared event specification.

The implementation will introduce a standardized event convention covering topic naming, versioning, indexed fields, and payload structure. I will update the relevant state-changing contracts—including the alert system, escrow, operator rotation, and governance modules—to emit events that conform to this specification while preserving existing contract behavior. Where appropriate, I will reuse existing event utilities rather than introducing duplicate abstractions.

In addition to the implementation, I will document the complete event catalog in EVENTS.md, detailing every event, its topics, payload schema, and when it is emitted. I will also add tests to verify that key state transitions publish the expected events, ensuring the event contract remains stable for downstream consumers. If backend event payload expectations already exist, I will align the implementation with those conventions to avoid introducing multiple competing schemas.

Why I'm a Good Fit

I have experience building backend systems and APIs where consistency, observability, and maintainability are essential. My background with TypeScript, distributed systems, and event-driven architectures enables me to approach this task from both the smart contract and backend indexing perspectives. Beyond implementing the required changes, I focus on producing clear documentation, robust tests, and maintainable interfaces that make future integrations easier for contributors and downstream services.

[grantfox-oss]

🦊 GrantFox — @jrcity has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #3)
2. Your PR will be reviewed by the stellar-kracken maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox!

@jrcity's PR #24 was approved and merged by @Meshmulla.

🏆 @jrcity: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (223 total points). Track your full progress on GrantFox.

👏 Great work, @jrcity! Keep contributing to stellar-kracken.