The ScrvusdVerifierV1 contract incorrectly calculates the storage slot for balanceOf(self) in the PARAM_SLOTS array. The slot is defined as keccak256(abi.encode(18, SCRVUSD)), which reverses the standard Solidity mapping slot calculation order (should be keccak256(abi.encode(SCRVUSD, 18))).
This results in an incorrect value being extracted for params[6], which is passed to the SCRVUSD_ORACLE for price updates, potentially incorrect calculations.
In the PARAM_SLOTS array:
The entry keccak256(abi.encode(18, SCRVUSD)) is intended to represent the storage slot for balanceOf(self).
For a standard Solidity mapping mapping(address => uint256) balanceOf at slot 18, the correct slot calculation is keccak256(abi.encode(SCRVUSD, 18)), with the key (SCRVUSD) preceding the base slot (18).
The reversed order (18, SCRVUSD) produces an incorrect hash, meaning the extracted params[6] does not correspond to balanceOf(SCRVUSD).
Incorrect Oracle Data: The SCRVUSD_ORACLE receives an incorrect params[6], which could skew price calculations or validation logic if balanceOf(self) is used.
Financial Risk: If the oracle’s output affects pricing, liquidity, or reserves in downstream contracts, this could lead to indirect financial losses or exploitable discrepancies.
Manual code review.
Correct the Slot Calculation: Update PARAM_SLOTS[7] to use the proper order
- Per sponsor comments, verified slot is vyper, solidity contract only verifies it. - Vyper computes storage slots different from solidity as seen [here](https://ethereum.stackexchange.com/questions/149311/storage-collision-in-vyper-hashmap)
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.