Summary

The ScrvusdVerifierV1 contract computes the storage slot for the vault's balance_of_self incorrectly by swapping the order of the mapping key and the mapping slot.

Instead of using keccak256(abi.encode(SCRVUSD, 18)) (where SCRVUSD is the vault's address and 18 is the storage slot), the code uses keccak256(abi.encode(18, SCRVUSD)). This error leads to the extraction of an incorrect balance, which in turn miscalculates the total supply and reported price.

Vulnerability Details

In Solidity, the storage location for a mapping value is computed using keccak256(abi.encode(key, slot)), where key is the mapping key (in this case, the vault's address, SCRVUSD) and slot is the designated storage slot number (here, assumed to be 18 for the balance mapping).

The verifier defines the slot for balance_of_self as follows:

https://github.com/CodeHawks-Contests/2025-03-curve/blob/main/contracts/scrvusd/verifiers/ScrvusdVerifierV1.sol#L32-#L41

According to storage layout for mappings, the correct slot should be computed as:

where the key (vault address) comes first and the mapping slot second.

By swapping the order, the verifier reads from an incorrect storage location, causing it to obtain a wrong value for balance_of_self. This value is subsequently used to derive critical parameters such as total_supply for the vault, directly affecting the computation of the oracle's raw_price.

Impact

In protocols like stableswap pools that rely on the oracle's price, such mispricing can be exploited to execute profitable arbitrage attacks or even drain the pool, resulting in significant financial losses for liquidity providers. Given the direct influence of the oracle price on asset redemption rates, the miscalculation poses a risk of irreversible economic damage even if all privileged roles are assumed to be trusted.

Tools Used

Manual Review

Recommendations

Update the storage slot computation in the verifier to: