Storage Proofs

Summary

This report documents a low-severity vulnerability identified in the ScrvusdVerifierV1.sol and ScrvusdVerifierV2.sol contracts, related to inconsistent access control. The issue stems from public functions that can be called by anyone but are only effective when invoked by users with specific roles in the dependent ScrvusdOracleV2.vy contract, leading to potential gas wastage and developer confusion.

Vulnerability Details

The vulnerability arises in the following functions:

• In ScrvusdVerifierV1.sol:

  • verifyScrvusdByBlockHash(bytes memory _block_header_rlp, bytes memory _proof_rlp) (external)

  • verifyScrvusdByStateRoot(uint256 _block_number, bytes memory _proof_rlp) (external)

• In ScrvusdVerifierV2.sol:

  • verifyPeriodByBlockHash(bytes memory _block_header_rlp, bytes memory _proof_rlp) (external)

  • verifyPeriodByStateRoot(uint256 _block_number, bytes memory _proof_rlp) (external)

These functions are defined as external, allowing any user or contract to call them without restriction. However, their outputs are only usable in the ScrvusdOracleV2.vy contract, where subsequent calls to update_price or update_profit_max_unlock_time are restricted by role-based access control:

• update_price requires the PRICE_PARAMETERS_VERIFIER role.

• update_profit_max_unlock_time requires the UNLOCK_TIME_VERIFIER role.

Since these verifier functions do not enforce access control internally, they can be executed by unauthorized users, but the results cannot be successfully passed to the oracle contract due to the role restrictions. This mismatch between the public visibility of the functions and their practical utility creates an inconsistency.

Impact

• Gas Wastage: Unauthorized users can call these verifier functions, spending gas on proof verification and parameter extraction, only to have the subsequent update_price or update_profit_max_unlock_time calls revert due to missing roles. This leads to unnecessary gas consumption.

• Developer Confusion: The public nature of these functions may mislead developers or integrators into assuming they are universally callable, whereas their effective use is restricted to specific roles in the oracle contract.

Tools Used

• Manual code review

• Solidity and Vyper syntax analysis

• No automated tools were used; the vulnerability was identified through logical inspection of function visibility and dependencies.

Recommendations

Restrict Access at the Verifier Level:

• Add role-based access control directly to the verifier functions using a modifier like onlyRole. This ensures that only authorized users can call these functions, aligning their visibility with their practical utility.