Storage Proofs

Summary

In ScrvusdVerifierV1.sol in the PARAM_SLOTS array initialization, specifically in how the storage slot for balanceOf(self) is calculated: #L32-L40

The root cause is that the arguments to abi.encode() are in the wrong order.

Technical Details

In Solidity, for a mapping mapping(address => uint256) stored at slot p, the storage slot for a specific key k is calculated as

Where:

• k is the mapping key (an address in this case)

• p is the slot number of the mapping itself

For the balanceOf mapping at slot 18, the correct storage slot for balanceOf[SCRVUSD] should be:

However, the code computes:

This reverses the arguments, computing an entirely different storage slot that doesn't correspond to any relevant data.

Vulnerability Details

In the code, they're computing keccak(abi.encode(18, SCRVUSD)), which would be h(18) followed by h(SCRVUSD), which is different. Therefore, the code is using the wrong slot for balanceOf, leading to incorrect data retrieval.

Impact

1. The balance_of_self parameter is critical for calculating.

   • The total supply of assets via the _total_supply() function

   • The amount of unlocked shares via _unlocked_shares()

   • The price of scrvUSD via _raw_price()

2. Since this oracle is intended for use in StableSwap pools, incorrect pricing would lead to.

   • Pools with incorrect asset ratios

   • Arbitrage opportunities that drain liquidity from pools

   • Financial losses for liquidity providers

3. Since this oracle system is designed to operate across multiple chains, the incorrect pricing would propagate to all integrated chains and protocols.

This is problematic because the entire purpose of the oracle is to provide accurate pricing, and this bug directly undermines that core functionality.

Recommendations

swap the argument order in the abi.encode call

This will ensure the correct storage slot is read, providing the actual balanceOf(self) value needed for accurate price calculations.