# Token: Founder percentages not always respected

Nouns Builder's greedy founder-mint loop over tokenRecipient[tokenId%100] skews founder token percentages, letting one founder capture far more than their configured share.

- Payout: Contest reward
- Severity: medium
- Program: Nouns Builder
- Credited: Lambda
- Disclosed: 2022-11-03
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-09-nouns-builder-findings/issues/107
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-nouns-builder%3AM-24
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** Token.sol founder minting / tokenRecipient schedule
**Root cause:** Founder tokens are minted greedily until _isForFounder returns false (first unset tokenRecipient[tokenId % 100]), so consecutive slots for one founder cause burst minting that deviates from configured founderPct.
**Steps:**
1. Configure founders with 51% and 48% shares; schedule=1 fills tokenRecipient[0..50] for founder1 and tokenRecipient[51], [53]... for founder2.
2. Trigger a mint when tokenId % 100 == 0 just before vestExpiry.
3. Observe founder1 receives 51 tokens (consecutive slots) while founder2 receives only 1.
4. If vestExpiry is short so only one mint hits founders, actual split becomes 51%/1% instead of 51%/48%.
**How found:** Code-reading of the greedy mint loop at Token.sol#L110; reasoned about the tokenRecipient[tokenId % 100] slot layout and constructed a concrete 51/48 schedule with a mint at tokenId%100==0 near vestExpiry.
**Insight:** When auditing percentage/schedule-based distribution, model the slot layout (tokenId % N) against boundary mints and short vesting windows; fuzz founderPct/schedule combos to expose skew rather than assuming long-run convergence.