Storage Proofs

Summary

The contract calculates the storage key for the balance of scrvUSD using the expression keccak256(abi.encode(18, SCRVUSD)). However, for fixed storage slots (like for a mapping entry), the proper approach is to encode the key and the slot in the correct order—typically using abi.encode(SCRVUSD, uint256(18)). The incorrect order results in an erroneous storage key, meaning that the contract will read from or write to the wrong location in storage.

Vulnerability Details

In Solidity, when you compute the storage slot of a mapping entry, the formula is:
keccak256(abi.encode(key, p))
where key is the mapping key and p is the slot number where the mapping is declared.

but the code uses :

This encodes the slot number (18) first and then the key (SCRVUSD). The order is reversed compared to the required order (key then slot).

Impact

-> With the wrong order, the hash value produced will not match the actual storage slot for the balance of scrvUSD. This leads to reading a zero value or a garbage value, causing the oracle’s price update to be based on incorrect data.

->If the oracle’s output is based on incorrect storage values, it may lead to mispriced assets or miscalculated rewards. This inaccuracy could eventually result in financial losses.

Recommendations

correct the ordering of the variables :