You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[CRITICAL][STELLAR NETWORK ISOLATION] Key projected events by network and filter activity accordingly #201
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.
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.
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.
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.
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.
Activity
Samaro1 commentedon Aug 17, 2026
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 commentedon Aug 21, 2026
Hello maintainer, I want to work on this issue.
k-deejah commentedon Aug 22, 2026
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 commentedon Aug 22, 2026
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 commentedon Aug 22, 2026
🦊 GrantFox — @edehvictor has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #201)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Aug 30, 2026
🎉 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.