# uint(-1) index for not found

Based Loans UniswapConfig lookup functions returned index 0 for missing token configs, which is also a valid index, so nonexistent configs resolved to the first config.

- Payout: Audit contest
- Severity: high
- Program: Based Loans
- Disclosed: 2021-05-27
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-04-basedloans-findings/issues/24
- Library page: https://bugbountylibrary.com/r/c4%3A2021-04-basedloans%3AH-02
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:high tech:evm tech:solidity vuln:accounting-error vuln:business-logic

**Target:** UniswapConfig token config lookup functions (getTokenConfigBySymbolHash, getTokenConfigByCToken, getTokenConfigByUnderlying)
**Root cause:** Lookup functions checked the returned index against `uint(-1)` to detect 'not found', but an uninitialized uint defaults to 0, so the sentinel can never be hit; missing configs return 0, which is also the valid index of the first config.
**Steps:**
1. Read `getTokenConfigBySymbolHash`, `getTokenConfigByCToken`, `getTokenConfigByUnderlying` in UniswapConfig.
2. Observe each checks `index != uint(-1)` to detect a missing config.
3. Note the mapping returns default 0 for unset keys, never uint(-1), so the check always passes.
4. Call a lookup with a nonexistent symbol/cToken/underlying and observe it returns index 0, the first config, instead of signaling not-found.
**How found:** Code review of the not-found sentinel logic: noticed the comparison against `uint(-1)` cannot be satisfied by a default-initialized mapping value, and that 0 collides with a valid index.
**Insight:** When a mapping lookup uses a sentinel for 'not found', verify the sentinel is actually reachable given Solidity's zero-default; if 0 is a valid index, reserve it or track initialization separately.