[CRITICAL][STELLAR NETWORK ISOLATION] Key projected events by network and filter activity accordingly

[Obiajulu-gif]

Summary

Raw indexer envelopes are network-scoped, but the projected StellarIndexedEvent model has no network field and uses the Horizon operation ID alone as _id. Testnet and mainnet projections can collide, and the activity API queries every projected record without constraining the configured network.

Repository evidence

• models/StellarIndexedEvent.ts:28-53 defines no network identity and documents _id as the operation/payment ID.
• lib/stellar/indexer.ts:213-240 correctly includes network in raw-envelope keys, but persistEvent projects into the networkless model.
• app/api/stellar/activity/route.ts:163-181 filters only by account (or nothing for admins), despite returning config.network in the response.

Scope

• Add immutable network identity to projected events and use a collision-safe compound identity.
• Backfill or rebuild legacy projections with explicit provenance and quarantine ambiguous records.
• Filter all activity and administrative queries by the selected network.

Acceptance criteria

• The same Horizon operation identifier can exist on testnet and mainnet without collision.
• No testnet event appears in a mainnet activity response, including admin responses.
• Network changes cannot silently relabel legacy networkless projections.

Tests

• Cross-network ID collision, account with activity on both networks, admin filtering, legacy ambiguous record, rebuild, and unique-index migration tests.

Non-goals

• Changing contiguous checkpoint or dead-letter behavior already handled by the raw indexer pipeline.

[Samaro1]

Gm gm boss. I would like to take this one on. I can add immutable network identity to the projected event model with a collision-safe compound identity, backfill or rebuild legacy projections with explicit provenance while quarantining ambiguous records, and filter all activity and admin queries by the configured network, covering it with the cross-network collision, dual-network account, admin filtering, and legacy record migration tests. Please assign it to me.

[Owolabenjade]

Hello maintainer, I want to work on this issue.

[k-deejah]

I’d like to take on this issue because network isolation is a critical correctness and security requirement for the Stellar activity system. The current projection layer can lose network provenance and allow Testnet and Mainnet events with the same Horizon operation ID to collide, which could result in incorrect activity being exposed.

I have experience working with Stellar/Soroban projects, TypeScript, backend logic, data models, and open-source repositories. I’m comfortable tracing an issue across the indexer, persistence layer, API queries, and tests rather than treating the problem in isolation.

For this issue, I would:

Add immutable network identity to StellarIndexedEvent and implement a collision-safe compound identity. Update event persistence so network provenance is preserved from the raw indexed envelope. Handle legacy networkless projections safely, including quarantining ambiguous records rather than silently assigning them to a network. Filter both user activity and administrative queries by the selected network. Add regression tests covering cross-network ID collisions, accounts active on both networks, admin filtering, legacy records, rebuilding/backfilling, and unique-index migration. Verify that changing the configured network cannot cause existing events to be silently relabeled.

I’ll also make sure the implementation stays within the scope of this issue and does not alter the existing checkpoint or dead-letter behavior.

I’m ready to investigate the current indexing and projection flow, implement the changes, and provide focused tests demonstrating that Mainnet and Testnet data remain strictly isolated.

[edehvictor]

Hi maintainers!
I’d love to help out with this issue. I’ve checked the current codebase/documentation and know exactly what needs to be updated to make this clearer. I will ensure everything aligns perfectly with your existing contribution guidelines.

[grantfox-oss]

🦊 GrantFox — @edehvictor has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

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

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox!

@edehvictor's PR #234 was approved and merged by @Obiajulu-gif.

🏆 @edehvictor: You earned 40 FoxPoints for this contribution! Your current tier: Builder (1,282 total points). Track your full progress on GrantFox.

👏 Great work, @edehvictor! Keep contributing to Chainmove.