Storage Proofs
Curve
DeFiLayer 1Layer 2
14,723 OP
View results
Previous Next
Submission Details
Severity: high
Invalid

State Proof Verification Risks: Hardcoded Storage Slot Dependency

ibukunola

Summary

The contract relies on a hardcoded storage slot (PERIOD_SLOT = 37) to extract the profit_max_unlock_time value from the scrvUSD contract’s storage via state proofs. If the scrvUSD contract’s storage layout changes (e.g., due to an upgrade or redeployment), the slot could become invalid, leading to incorrect profit_max_unlock_time values being passed to the oracle.

Vulnerability Details

  • Description: The _extractPeriodFromProof function uses PERIOD_SLOT = 37 to fetch the profit_max_unlock_time value:

Verifier.SlotValue memory slot = Verifier.extractSlotValueFromProof(
keccak256(abi.encode(PERIOD_SLOT)),
account.storageRoot,
proofs[1].toList()
);

This slot is hardcoded and assumes a specific storage layout in the scrvUSD contract. In the Vyper IScrvusdOracle contract provided earlier, profit_max_unlock_time is indeed at slot 37 (based on its position in the storage layout), but any change to the scrvUSD contract’s structure (e.g., adding new variables, upgrading the contract) could shift this slot, rendering the hardcoded value incorrect.
Root Cause: Use of a hardcoded storage slot (PERIOD_SLOT = 37) without a mechanism to adapt to changes in the target contract’s storage layout.

Impact

  • Severity:
    High

  • Description:
    An incorrect profit_max_unlock_time value could be extracted and passed to the oracle, altering profit unlocking schedules in downstream systems (e.g., scrvUSD vault, StableSwap pools). This could lead to financial losses if profits are unlocked too quickly or slowly, disrupting the economic model of the system.
    Likelihood: Medium, as it depends on future changes to the scrvUSD contract, but the risk is undeniable given the hardcoded nature of the slot.
    Tools Used
    Manual Code Review: Multiple passes to confirm the use of PERIOD_SLOT and its implications.
    Solidity Knowledge: Applied understanding of storage layouts, state proof verification, and the risks of hardcoded slots.
    Vyper Context: Cross-referenced the Vyper IScrvusdOracle contract to validate the current slot alignment.

Recommendations

  • Dynamic Slot Calculation: Replace the hardcoded PERIOD_SLOT with a configurable or dynamically fetched value:

uint256 public periodSlot; // Configurable slot
address public owner; // Add ownership for configuration
modifier onlyOwner() {
require(msg.sender == owner, "Not owner");
_;
}
constructor(address _block_hash_oracle, address _scrvusd_oracle, uint256 _periodSlot)
ScrvusdVerifierV1(_block_hash_oracle, _scrvusd_oracle) {
periodSlot = _periodSlot;
owner = msg.sender;
}
function setPeriodSlot(uint256 _slot) external onlyOwner {
periodSlot = _slot;
}
Updates

Lead Judging Commences

0xnevi Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Out of scope
Assigned finding tags:

[invalid] finding-upgradeable-verifier-contracts

Invalid, - srCRVUSD is a minimal proxy, meaning it can never by upgraded, see [here](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern#:~:text=Minimal%20proxies%20are%20distinct%20from,provide%20upgrade%20or%20authorization%20functionality.) and [here](https://www.rareskills.io/post/eip-1167-minimal-proxy-standard-with-initialization-clone-pattern) for more info. - Even if srcrvUSD is migrated in the future via a new minimal proxy contract deployment (which is highly unlikely), the verifier contracts can be migrated along with it via revoking the access-control within the `ScrvusdOracleV2.vy` and then granting access to a new oracle. This is also not within the scope of this contest.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.