No off-chain event indexer — every page load re-derives state from raw RPC calls

[Ejirowebfi]

🔴 Critical · .kiro/specs/contract-event-indexing/ (currently empty), issues #22/#23 above

Description

There is an empty spec directory literally named contract-event-indexing, confirming the team has already identified this gap but not yet scoped or built it. As demonstrated concretely by issue #22 (the 100-event hard cap silently truncating the explorer) and #23 (sequential pagination latency), the frontend's entire data layer is built on live, synchronous RPC calls to Soroban/Horizon with a thin, short-TTL, unbounded in-memory cache (#21) as the only persistence — there is no off-chain service that ingests factory events once and serves fast, complete, paginated, filterable queries over them. This architecture fundamentally cannot scale past a few hundred tokens without either the truncation bug (#22) or unacceptable load times (#23), and every RPC-endpoint outage or rate-limit event (#34) takes down the entire app's data-reading capability simultaneously, since there's no cached fallback layer.

Tasks

• Scope the empty .kiro/specs/contract-event-indexing/ spec: define whether the indexer is a simple serverless cron job periodically ingesting events into a lightweight database (e.g. a Cloudflare D1/Vercel Postgres table of TokenInfo rows keyed by contract address, kept in sync via periodic getEvents polling or a Soroban RPC event subscription if available), or a more substantial dedicated service.
• Define the indexer's API surface the frontend would consume (e.g. GET /api/tokens?creator=&offset=&limit=, GET /api/tokens/:address) mirroring but not replacing the on-chain view functions (the indexer is a read-optimization layer, not a source of truth — the frontend should still be able to fall back to direct RPC calls if the indexer is unavailable or the user wants to verify against the chain directly).
• Build a minimal first version covering just the "all tokens" explorer view (directly fixing issue Add Select / Dropdown UI Component #22's truncation) as the initial milestone, before expanding to per-creator queries, search/filter, and transaction history.
• Add monitoring/alerting for indexer lag (time since last successfully-ingested event) so staleness is visible rather than silent.

Acceptance Criteria

• A scoped design document fills in the currently-empty contract-event-indexing spec.
• A first working version serves the "all tokens" explorer view completely and correctly (no 100-event truncation), verified against a testnet deployment with more than 100 tokens created.
• The frontend has a documented, tested fallback path to direct RPC calls if the indexer is unreachable.

[giftexceed]

I'd like to work on this issue.

I'm a backend and blockchain developer with experience designing scalable data pipelines, REST APIs, caching layers, and event-driven systems. I've worked with TypeScript, Node.js, PostgreSQL, and blockchain integrations, focusing on performance, reliability, and maintainability.

For this issue, I will define a clear architecture for the off-chain event indexer, document the API and synchronization strategy, implement an initial indexer for the token explorer, and provide a reliable frontend fallback to direct RPC calls. I'll also document monitoring for indexer lag to ensure data freshness and operational visibility while keeping the solution scalable and easy to extend.

[Dennis-Ritchie1]

hello maintainers i would like to work on this issues
have gone the issues and understand it how to solved it

[grantfox-oss]

🦊 GrantFox — @Dennis-Ritchie1 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 #943)
2. Your PR will be reviewed by the Favourorg maintainers

Good luck! Track your progress on GrantFox.