# emissions/keeper/GetIdsOfActiveTopics may always return empty array []

GetIdsOfActiveTopics paginates from key 0, so if no active topic has id 0, iteration returns empty and topic weights never update.

- Payout: Contest reward
- Severity: high
- Program: Allora
- Credited: Kow
- Disclosed: 2024-06-24
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2024-06-allora-judging/issues/91
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-allora%3AH-12
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:high tech:go technique:source-review vuln:business-logic vuln:dos

**Target:** Cosmos SDK emissions keeper GetIdsOfActiveTopics pagination
**Root cause:** IterateRaw is called with startKey=0 while activeTopics keys may all be >0; the range [0, limit) matches nothing, returning nil keys and nextKey reset to empty, so the paging loop never advances.
**Steps:**
1. Create topics with ids 20..99 and activate them, leaving no topic with id 0.
2. Call `GetIdsOfActiveTopics` with `SimpleCursorPaginationRequest{Key: [], Limit: 10}`.
3. Observe `IterateRaw(ctx, startKey=0, nextKey=10)` returns no keys because stored keys are >=20.
4. Function returns empty activeTopics and NextKey=[]; SafeApplyFuncOnAllActiveEpochEndingTopics loops with unchanged topicPageKey forever.
**How found:** Code reading of the pagination helper: noticed startKey initialized to zero bytes and reasoned that IterateRaw over a range starting at 0 misses keys whose ids begin above the limit; confirmed with a unit test seeding topics 20-99.
**Exploitation:** Attacker creates pageLimit topics that are never activated, ensuring no active topic id falls in the first key range; EndBlocker's GetAndUpdateActiveTopicWeights then iterates nothing, so topic weights and rewards are never processed.
**Insight:** When auditing cursor pagination over keyed stores, check whether the initial cursor is a valid lower bound for actual key distribution; a zero start key silently skips all keys above the first page window.