DETAILS

The contracts hardcode the SCRVUSD contract address, its keccak256 hash, and the storage slots for the parameters being verified. Similarly, ScrvusdVerifierV2 hardcodes PERIOD_SLOT. If the SCRVUSD contract address changes due to upgrades or migrations, or if its storage layout is modified, these verifier contracts will become incompatible and cease to function correctly. This necessitates redeployment of the verifier contracts whenever the underlying SCRVUSD contract is updated in a breaking way.

Tools Used

Proof of Concept (PoC) Scenario:

1. Setup: Deploy ScrvusdVerifierV1 with the current, correct SCRVUSD address.

2. Simulate Address Change: Imagine the SCRVUSD contract is upgraded and deployed to a new address.

3. Execution: Attempt to use the deployed ScrvusdVerifierV1 with state proofs from the new SCRVUSD contract at the new address.

4. Outcome: The verifier will still be using the old, hardcoded SCRVUSD_HASH. The Verifier.extractAccountFromProof function will likely fail to find the account at the new address using the old hash, or if it does, the storage proofs might be invalid if the storage layout has changed. The verification process will break, and price updates will fail.

Recommendations

• Configuration via Constructor/Admin: Make the SCRVUSD address and storage slots configurable during contract deployment or through an admin function.

• Upgradeable Proxy Pattern: Implement an upgradeable proxy pattern for the verifier contracts. This allows for updating the implementation logic (including address and slot configurations) without changing the proxy address that other contracts interact with.

• External Configuration Contract: Consider using an external configuration contract to store and manage configurable parameters like the SCRVUSD address and storage slots. The verifier contracts can then read these parameters from the configuration contract.