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

Role-Based Access Control Lacks Time Delay for Critical Operations

Summary

While the contract implements proper role-based access control, critical operations can be executed immediately by authorized roles. Although this follows standard practices, adding a time delay could provide additional security through increased transparency.

Vulnerability Details

The ScrvusdOracleV2 contract uses role-based access control to restrict who can call sensitive functions:

  • update_price: Updates the oracle's price parameters and is restricted to addresses with the PRICE_PARAMETERS_VERIFIER role.

  • update_profit_max_unlock_time: Adjusts the profit_max_unlock_time parameter, which affects price calculations, and is restricted to addresses with the UNLOCK_TIME_VERIFIER role.

While these functions are protected by role-based permissions, there is no mechanism to delay their execution. Once a role holder (e.g., a verifier) initiates a call, the change takes effect immediately. This design flaw becomes critical if a role holder's private key is compromised—through phishing, theft, or insider threats—allowing an attacker to instantly alter the oracle's behavior without any opportunity for detection or intervention.

Impact

Immediate Price Manipulation: A compromised role holder could instantly manipulate the oracle's price or parameters, leading to mispricing in dependent systems like stableswap-ng pools. This could create arbitrage opportunities or, in severe cases, drain pool funds.

Tools Used

Recommendations

To address this vulnerability and enhance the security of the ScrvusdOracleV2 contract, consider the following mitigations:

Add a Timelock for Critical Operations

Introduce a timelock mechanism that delays the execution of update_price and update_profit_max_unlock_time. For example, enforce a 24-48 hour delay before changes take effect, giving administrators or the community time to review and respond to suspicious updates.

Implement Multi-Signature Requirements

Require approval from multiple authorized role holders before critical updates are applied. For instance, mandate that at least two out of three verifiers approve a change, reducing the risk of a single compromised account causing harm.

Updates

Lead Judging Commences

0xnevi Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
Assigned finding tags:

[invalid] finding-centralization-risk

- Per [codehawks documentation](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#findings-that-may-be-invalid) - Parameter change is executed via the Dao per docs > Also, it is worth noting that the oracle is controlled by a DAO and its parameters can be changed by a vote.

Support

FAQs

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