Skip to content

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

Closed

Description

@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.

Activity

  1. Samaro1 commented on Aug 17, 2026

    @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.

  2. Owolabenjade commented on Aug 21, 2026

    @Owolabenjade
    Contributor

    Hello maintainer, I want to work on this issue.

  3. k-deejah commented on Aug 22, 2026

    @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.

  4. edehvictor commented on Aug 22, 2026

    @edehvictor
    Contributor

    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.

  5. grantfox-oss commented on Aug 22, 2026

    @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.

  6. grantfox-oss commented on Aug 30, 2026

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardThird CampaignCampaign: Third Campaign

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions