# MarketFees: Primary sales not detected in some scenarios

MarketFees loop breaks early on an invalid creatorShare, so a seller who is also a royalty recipient is misclassified as a secondary sale, misrouting fees.

- Payout: Audit contest
- Severity: medium
- Program: Foundation
- Disclosed: 2022-12-14
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2022-11-foundation#m-02
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-foundation%3AM-02
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity vuln:accounting-error vuln:business-logic vuln:fee-bypass

**Target:** MarketFees.sol fee-splitting logic in NFT marketplace contracts
**Root cause:** The creatorShares loop breaks when any entry exceeds BASIS_POINTS, skipping later iterations; the seller-recipient check that zeroes sellerRev never runs for recipients after the invalid entry.
**Steps:**
1. Set creatorRecipients = [Bob, Alice, seller] and creatorShares = [100, 10_001, 100].
2. Call the sale/fee calculation path that iterates creatorShares.
3. Observe loop breaks at index 1 (10_001 > BASIS_POINTS), so index 2 (seller) is never compared.
4. sellerRev is not set to 0, so the sale is treated as secondary instead of primary.
**How found:** Code reading of the fee loop: noticed the early break on invalid shares and reasoned it could skip the seller-recipient detection later in the array.
**Exploitation:** A seller who is also a royalty recipient in a position after an invalid share entry gets secondary-sale fee treatment instead of primary, misallocating royalty/fee revenue.
**Insight:** When auditing fee-splitting loops, check whether early exits/breaks skip later state-mutating checks (like seller-recipient detection) that depend on full iteration.

