DeFiLayer 1Layer 2
14,723 OP
View results
Submission Details
Severity: low
Invalid

Inconsistent Block Number Validation for duplicate state variable

Summary

The ScrvusdOracleV2.vy Oracle uses a single last_block_number variable for both price parameters and unlock time updates, which could lead to validation issues.

Vulnerability Details

The contract uses the same state variable to track updates from two different sources:

last_block_number: public(uint256) # Warning: used both for price parameters and unlock_time

If two different verification sources (price and unlock time) use different block heights, this can lead to inconsistencies.

If two updates occur in the same block (e.g., price update at block N and unlock time update at block N), the later update could overwrite the earlier one.

If updates are staggered, stale data from older blocks could bypass validation (e.g., a delayed unlock time update with an older block number).

Impact

This could potentially allow out-of-order updates or block legitimate updates if different parameters are updated at different frequencies.

Tools Used

Manual Review

Recommendations

Use separate block number tracking for each type of update:

last_price_block_number: public(uint256) last_unlock_time_block_number: public(uint256)

And update the validation logic accordingly in each function.

Updates

Lead Judging Commences

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

[invalid] finding-block-number-no-input-check

- Anything related to the output by the `BLOCK_HASH_ORACLE` is OOS per \[docs here]\(<https://github.com/CodeHawks-Contests/2025-03-curve?tab=readme-ov-file#blockhash-oracle>). - The PoC utilizes a mock `BLOCK_HASH_ORACLE`which is not representative of the one used by the protocol - Even when block hash returned is incorrect, the assumption is already explicitly made known in the docs, and the contract allows a subsequent update within the same block to update and correct prices - All state roots and proofs must be verified by the OOS `StateProofVerifier` inherited as `Verifier`, so there is no proof that manipulating block timestamp/block number/inputs can affect a price update - There seems to be a lot of confusion on the block hash check. The block hash check is a unique identifier of a block and has nothing to do with the state root. All value verifications is performed by the OOS Verifier contract as mentioned above

Support

FAQs

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