Summary

The Solidity verifier contracts (ScrvusdVerifierV1 and ScrvusdVerifierV2) incorrectly calculate the storage slot for the balance_of_self parameter. The current implementation uses keccak256(abi.encode(18, SCRVUSD)), which reverses the order of arguments required by Solidity's storage layout rules. This results in reading from an incorrect storage location, leading to inaccurate data retrieval and potentially compromising the oracle's functionality.

Vulnerability Details

Solidity calculates storage slots for mappings as

• key: The mapping key (here, SCRVUSD, the contract’s own address).

• mapping_slot: The declared storage slot of the mapping (here, 18).

The verifier incorrectly reverses the order:

This computes a non-existent storage slot, causing the oracle to read arbitrary data from an unintended location.

Example

Assume:

• SCRVUSD = 0x...123 (contract address).

• Correct slot: keccak256(abi.encode(0x...123, 18)).

• Current slot: keccak256(abi.encode(18, 0x...123)) → Produces a different hash.

The verifier will read balance_of_self from a slot unrelated to the actual value, leading to corrupted data.

Impact

The verifier reads the balance_of_self value from an incorrect storage slot, leading to inaccurate data.

Tools Used

Manual Code Review

Recommendations

Fix the Storage Slot Calculation:

• Update the PARAM_SLOTS array to use the correct order of arguments:

  uint256(keccak256(abi.encode(SCRVUSD, 18)))