Storage Proofs

[M-01] Integer Overflow in ScrvusdOracleV2::_unlocked_shares Calculation

Summary:
The ScrvusdOracleV2::_unlocked_shares function performs arithmetic operations without overflow checks. This could lead to unintended behavior if values are large enough to cause an overflow.

Vulnerability Details:
The Calculation at line 207

If ts - last_profit_update is too large, multiplication with profit_unlocking_rate may overflow, leading to incorrect values.

Impact:
Incorrect unlocking of shares could cause improper profit distribution, leading to loss or misallocation of funds.

Tools Used:
Manual review of the contract.

Recommendations:
Implement overflow checks using safe arithmetic functions or limit ts - last_profit_update to a reasonable range.

[M-02] Unrestricted Same-Block Price Updates Allow Potential Manipulation

Summary:
The ScrvusdOracleV2::update_price function allows multiple updates within the same block, which could enable price manipulation within a single transaction. While this feature exists to correct bad blockhash issues, it also introduces a potential risk where rapid updates could be leveraged to manipulate the oracle price.

Vulnerability Details:
The function permits multiple updates in a single block without additional validation:

This only ensures that the _block_number is not outdated but does not prevent multiple updates within the same block. Since the price calculation depends on _parameters and _ts, an attacker with privileged access or control over oracle input data could update prices multiple times within a block, causing abnormal price fluctuations.

Impact:
Enables potential price manipulation if an attacker can repeatedly update prices in the same block,
May cause unexpected behavior in DeFi protocols relying on this oracle, as downstream systems depend on stable price updates.

Tools Used:
Manual review

Recommendations:
Modify the assertion to prevent same-block updates:

Implement a Cooldown period by enforcing a minimum time delay between updates

This ensures attackers cannot spam updates to manipulate the oracle price.

If multiple updates within a block are necessary, consider rate-limiting the magnitude of change to prevent price swings.

[M-03] Lack of Events for Important State Changes

Summary:
The contract lacks event emissions for key state updates, specifically when verifying scrvUSD and updating prices. This impacts transparency and off-chain monitoring.

Vulnerability Details:
The contract performs critical actions, such as verifying scrvUSD via block hash or state root and updating prices through an oracle. However, these actions do not emit events, making it difficult for external services (e.g., indexers, monitoring tools) to track state changes.

Affected functions:
ScrvusdVerifierV1::verifyScrvusdByBlockHash(),
ScrvusdVerifierV1::verifyScrvusdByStateRoot(),
ScrvusdVerifierV1::_updatePrice()

Without events, off-chain services cannot easily detect when a verification or price update occurs.

Impact:
Lack of transparency: Users and external systems cannot monitor verification and price updates in real-time.
Harder debugging: Developers and auditors must rely on manual state inspection instead of event logs.
Inefficient off-chain integration: DApps, analytics tools, and third-party services tracking scrvUSD updates would have to rely on polling instead of listening to events.
While this does not introduce security risks, it degrades usability and system monitoring.

Tools Used:
Manual Review of the contract

Recommendations:
Emit events when verification and price updates occur to improve transparency.

[M-04] Missing Events in ScrvusdVerifierV2

Summary:
The ScrvusdVerifierV2 contract lacks event emissions when the profit_max_unlock_time parameter is updated. Events are crucial for off-chain monitoring and debugging.

Vulnerability Details:
The functions ScrvusdVerifierV2::verifyPeriodByBlockHash() and ScrvusdVerifierV2::verifyPeriodByStateRoot() both call:

However, no event is emitted before or after this state update, making it difficult to track changes efficiently.

Impact:
Off-chain services relying on event logs (such as indexers and monitoring tools) won’t be able to detect updates.
Debugging and analytics tools might need to rely on transaction traces, which is more expensive than event logs.

Tools Used:
Manual review of the contract.

Recommendations:
Emit an event when profit_max_unlock_time is updated.