# Wrong reserves calculated for non-19 decimals points tokens

Canto BaseV1-periphery calculateFairReserves divides sqrt of reserves by 1e18, but reserves are already 18 decimals, so pairs with non-18-decimal tokens get wrong fair reserves.

- Payout: Audit contest
- Severity: high
- Program: Canto
- Disclosed: 2022-07-10
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2022-07-canto#h-03
- Library page: http://bugbountylibrary.com/r/c4%3A2022-07-canto%3AH-03
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity vuln:accounting-error vuln:precision-loss

**Target:** BaseV1-periphery.sol calculateFairReserves (AMM periphery)
**Root cause:** calculateFairReserves computes sqrt(reserve) and divides by 1e18 to normalize to 18 decimals, but the reserve values are already 18-decimal normalized, so the extra division corrupts the result for tokens whose native decimals differ from 18.
**Steps:**
1. Open `calculateFairReserves` in `src/Swap/BaseV1-periphery.sol` (line 568).
2. Observe it takes sqrt of each reserve and divides by `1e18` to 'normalize' to 18 decimals.
3. Note reserves are already 18-decimal values, so the division is spurious.
4. For a pair with a token that does not have 18 decimals, the computed fair reserves are wrong.
**How found:** Code review of the fair-reserve math: noticed the sqrt result was divided by 1e18 under the assumption reserves were not normalized, contradicting the fact reserves are already 18-decimal.
**Insight:** When auditing AMM math, check every normalization constant against the actual decimal basis of the inputs; a redundant 1e18 scaling silently breaks only non-18-decimal pairs, which standard tests miss.