# Oracle is tracked per token instead of per pair, leading to surprise results

VaultFactory stores oracles keyed by single token, so a second pair (ibBTC-renBTC) silently reuses the first pair's oracle, yielding wrong peg results.

- Payout: Contest reward
- Severity: medium
- Program: Y2k Finance
- Credited: PwnPatrol
- Disclosed: 2023-01-09
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-09-y2k-finance-findings/issues/100
- Library page: https://bugbountylibrary.com/r/c4%3A2022-09-y2k-finance%3AM-01
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:oracle-manipulation

**Target:** VaultFactory.sol oracle registry (tokenToOracle mapping)
**Root cause:** tokenToOracle is keyed by a single token rather than the token pair, and conflicting assignments are silently skipped when a value already exists, so a new pair inherits an unrelated oracle.
**Steps:**
1. Deploy ibBTC-wBTC pair with oracle O1; `tokenToOracle[ibBTC] = O1`.
2. Deploy ibBTC-renBTC pair with oracle O2; assignment hits `if (tokenToOracle[_token] == address(0))` guard and is skipped.
3. ibBTC-renBTC now resolves to O1 (ibBTC-wBTC oracle).
4. If wBTC diverges from renBTC or ibBTC/renBTC depeg, the pair's oracle returns incorrect prices.
**How found:** Code reading of VaultFactory oracle registration: noticed oracles tracked per token, and that the zero-check guard silently drops conflicting oracle assignments for new pairs sharing a token.
**Insight:** When a registry is keyed by one element of a composite identity, check what happens on collision: silent skip-if-set guards turn a naming assumption into a wrong-oracle bug for any asset lacking a canonical reference (e.g. BTC).