# Original collection referrer will be overwritten when a new collection/work is created

FeeManager stores collection referrer keyed by Edition, so publishing a second Work on the same Edition overwrites the first referrer, diverting their fees.

- Payout: Contest reward
- Severity: high
- Program: Titles
- Credited: 14si2o_Flint
- Disclosed: 2024-04-17
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-04-titles-judging/issues/265
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-04-titles%3AH-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** FeeManager.createRoute / TitlesCore.publish (Solidity)
**Root cause:** referrers mapping is keyed by Edition rather than by route (edition+tokenId), so each new Work published on the same Edition overwrites the stored collection referrer.
**Steps:**
1. Alice refers Bob; Bob calls `TitlesCore.publish(Edition_A, payload, Alice)` → `referrers[Edition_A] = Alice`.
2. Charles refers David; David calls `TitlesCore.publish(Edition_A, payload, Charles)` → `referrers[Edition_A] = Charles`.
3. Mint a token of Collection_A; `_splitProtocolFee` reads `referrers[Edition_A]` = Charles, routing collection referrer share to Charles instead of Alice.
**How found:** Code reading of createRoute and _splitProtocolFee revealed the referrers mapping keyed by edition_ while fee routes are keyed by getRouteId(edition_, tokenId_), exposing the key mismatch.
**Exploitation:** Any user can publish a new Work on an existing Edition with their own referrer address, overwriting the stored collection referrer and redirecting all future collection-referrer fees for that Edition to themselves.
**Insight:** When a protocol distinguishes per-collection vs per-edition state, check that fee/referrer mappings are keyed at the same granularity as the entity that earns them; a coarser key lets later creations hijack earlier entitlements.