# `ERC4626Oracle` Price will be wrong when the ERC4626's `decimals` is different from the underlying token’s decimals

ERC4626Oracle used the vault's decimals instead of the underlying asset's decimals, mispricing ERC4626 vaults whose decimals differ from the underlying token.

- Payout: Contest reward
- Severity: high
- Program: Sentiment
- Credited: Lambda
- Disclosed: 2022-08-30
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-08-sentiment-judging/tree/main/025-H
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-08-sentiment%3AH-4
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:oracle-manipulation

**Target:** ERC4626Oracle.getPrice price oracle
**Root cause:** getPrice() scales previewRedeem output by the ERC4626 vault's own decimals rather than the underlying asset's decimals, but EIP-4626 does not require them to match.
**Steps:**
1. Deploy/point at an ERC4626 vault whose decimals differ from its underlying asset's decimals
2. Call `ERC4626Oracle.getPrice(vault)`
3. Observe the returned price is scaled by `10 ** IERC4626(token).decimals()` instead of `10 ** IERC20Metadata(asset).decimals()`
4. Result: price underestimated when underlying decimals > vault decimals, overestimated when underlying decimals < vault decimals
**How found:** Code reading of getPrice() against the EIP-4626 spec, noting the spec only recommends (not requires) mirroring underlying decimals.
**Exploitation:** Not described beyond mispricing; a mispriced collateral asset in the lending market could be used to borrow beyond fair value or trigger unfair liquidations.
**Insight:** When integrating EIP-4626, never assume vault decimals equal asset decimals; always read decimals from the underlying asset for scaling, since the spec only 'strongly recommends' mirroring.