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

New max_price_increment not checked for StableSwap's minimum fee

Summary

The function set_max_price_increment includes a documentation note stating:

“The new value must be less than the StableSwap’s minimum fee.

fee / (2 * block_time) is considered to be safe.”

However, this constraint is not enforced in the code, meaning _max_price_increment can be set higher than the StableSwap’s minimum fee without restriction.

Vulnerability Details

In the ScrUsdOracleV2.vy::set_max_price_increment function documentation, it explicitly states:

Must be less than StableSwap’s minimum fee. fee / (2 * block_time) is considered to be safe

However, the actual implementation does not enforce this constraint, meaning the value can be set without verifying it against StableSwap’s minimum fee.

@external
def set_max_price_increment(_max_price_increment: uint256):
"""
@notice Set maximum price increment of scrvUSD.
Must be less than StableSwap's minimum fee.
fee / (2 * block_time) is considered to be safe.
@param _max_price_increment Maximum acceleration (per sec)
"""
access_control._check_role(access_control.DEFAULT_ADMIN_ROLE, msg.sender)
assert 10**8 <= _max_price_increment and _max_price_increment <= 10**18
self.max_price_increment = _max_price_increment
log SetMaxPriceIncrement(_max_price_increment)

Impact

• Admins may inadvertently set the max_price_increment above the safe threshold.

• Potential confusion or misconfiguration, leading to unexpected behavior or price instability.

Tools Used

Manual audit

Recommendations

• Implement an explicit check in the code enforcing that the _max_price_increment provided is less than the current StableSwap minimum fee divided by (2 * block_time) to match the documented specification.

Updates

Lead Judging Commences

0xnevi Lead Judge 3 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

[invalid] finding-max-price-increment-check-fee

- Explicitly stated in the docs, so it is presumed that the DAO owning the DEFAULT_ADMIN_ROLE role will not make such a mistake - See [here](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#findings-that-may-be-invalid), where admin input errors can be considered as invalid

Support

FAQs

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