# Truncation in casting can lead to a founder receiving all the base tokens

Unsafe uint8 truncation of founder ownership percentages in Nouns Builder Token.initialize lets a founder capture all base token IDs.

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

**Target:** Token.sol initialize / founder ownership scheduling
**Root cause:** founderPct (uint256) is truncated to uint8 when summed into totalOwnership, so the >100 check passes while the untruncated value is used for schedule = 100/founderPct, yielding 0 and misassigning base token IDs.
**Steps:**
1. Deploy Token implementation and ERC1967 proxy.
2. Call `initialize` with two founders each `ownershipPct: 256`.
3. uint8(256)=0 so totalOwnership check passes.
4. schedule = 100/256 = 0, baseTokenId never advances via schedule; `_getNextTokenId` increments by 1.
5. Assert `getScheduledRecipient(i).wallet == chadFounder` for i in 0..99 — first founder owns all base IDs.
**How found:** Code review of initialize's ownership summation noticed the uint8 cast on founderPct diverging from the uint256 value later used to compute schedule; confirmed with a Foundry PoC.
**Exploitation:** At deployment, a deployer sets founder percentages whose uint8 truncation sums ≤100 while actual values exceed 100, causing schedule=0 and all base token IDs (mod 100) to be assigned to the first founder, denying other founders their share.
**Insight:** When a value is validated after a narrowing cast but consumed in its original width, check for divergence — here uint8 truncation bypasses the ≤100 sum check while the full uint256 drives division, producing zero schedule.