Summary

The contract ScrvusdVerifierV1 contains an incorrect calculation of the storage slot for the balanceOf mapping in the PARAM_SLOTS array. The issue arises from the incorrect order of arguments in the keccak256(abi.encode(...)) function, which is used to compute the storage slot for a mapping entry. This results in the contract reading from or writing to an incorrect storage location, potentially leading to unintended behavior or vulnerabilities.

Affected code: ScrvusdVerifierV1::PARAM_SLOT

Vulnerability Details

Root Cause

In Solidity, the storage slot for a mapping entry is calculated as:

Where:

• key is the mapping key (e.g., an address).

• slot is the storage slot where the mapping itself is stored.

In the contract, the following calculation is used:

Here, 18 is treated as the key, and SCRVUSD is treated as the slot. This is incorrect because:

1. The slot (where the mapping is stored) should be 18.

2. The key (the address whose balance is being looked up) should be SCRVUSD.

The correct calculation should be:

Location

The issue is located in the PARAM_SLOTS array initialization in the ScrvusdVerifierV1 contract:

Technical Impact

The incorrect storage slot calculation for balanceOf(self) in PARAM_SLOTS causes the _extractParametersFromProof function to read from an unintended storage location. This results in:

1. Incorrect parameter Values Passed to _updatePrice:

• params[6] (balance of scrvUSD) will contain a value from the wrong storage slot, leading to incorrect data being used in price calculations.

1. Faulty Price Calculations in _updatePrice:

   • If the incorrect slot contains 0, the contract may assume a zero balance, skewing the price.

   • If the incorrect slot contains a large value, the price may be artificially inflated or deflated, causing financial discrepancies.

2. Failure of State Proof Verification Mechanism:

   • Extracted slot values may not match the state proof, causing reverts or silent acceptance of incorrect data, undermining the system's reliability.

Impact

Severity

• High: The issue affects the core functionality of the contract, as it involves reading and writing to storage, which is critical for the contract's operation. Incorrect storage access can lead to severe consequences, including financial losses or exploitation.

Likelihood

• High: The issue is guaranteed to occur whenever the balanceOf mapping is accessed, as the storage slot calculation is hardcoded and incorrect.

Tools Used

1. Manual Code Review

Recommendations

Update the PARAM_SLOTS array to use the correct storage slot calculation: