# Funding amount is accounted twice leading to activating topic before reaching the global minimum

Allora FundTopic adds the funded amount to topic fee revenue, then passes it again to weight calculation, double-counting and activating topics below the minimum weight.

- Payout: Contest reward
- Severity: medium
- Program: Allora
- Credited: 0x3b
- Disclosed: 2024-06-24
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-06-allora-judging/issues/46
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-allora%3AM-11
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Cosmos SDK emissions module FundTopic / topic activation weight calculation
**Root cause:** FundTopic calls AddTopicFeeRevenue to persist the amount, then passes the same amount as additionalRevenue to GetCurrentTopicWeight, which adds it again to the already-updated topicFeeRevenue.
**Steps:**
1. Call `FundTopic` with amount A on an inactive topic.
2. `AddTopicFeeRevenue` writes topicFeeRevenue += A.
3. `activateTopicIfWeightAtLeastGlobalMin` calls `GetCurrentTopicWeight(..., amount=A)`.
4. `GetCurrentTopicWeight` computes newFeeRevenue = A + topicFeeRevenue (A counted twice).
5. Overestimated weight >= MinTopicWeight triggers `ActivateTopic` prematurely.
6. PoC: run `go test ./keeper/msgserver/... -v -run "TestMsgServerTestSuite/TestPocDoubleAccounting"`; weight 304.29 vs correct 215.17, min 100.
**How found:** Code reading of FundTopic flow: noticed AddTopicFeeRevenue mutates state, then the same amount is passed as additionalRevenue into GetCurrentTopicWeight which re-adds it.
**Exploitation:** Attacker funds a topic with a small amount; the doubled revenue inflates computed weight past MinTopicWeight, activating the topic before it genuinely meets the global minimum.
**Insight:** When a function both persists a value and passes it as an 'additional' parameter to a weight/score calculation, check whether the calculation re-reads the already-updated state — double counting is easy to miss across call boundaries.