Algo Ssstablecoinsss
AI First Flight #2
Beginner FriendlyDeFi
EXP
View results
Previous Next
Submission Details
Severity: medium
Valid

Inflexible Oracle Staleness Check Creates Availability and Accuracy Risks

0xki

Root + Impact

Description

  • The oracle freshness validation uses a hardcoded staleness threshold that cannot adapt to changing market conditions or asset-specific requirements. This rigid approach creates operational risks in both volatile and stable market environments.


The staleness check is defined as a compile-time constant in oracle_lib.vy:

TIMEOUT: constant(uint256) = 72 * 3600 # 259,200 seconds
​

This fixed 72-hour window applies uniformly regardless of:

  • Market volatility levels

  • Asset liquidity characteristics

  • Oracle update frequency capabilities

  • Protocol operational requirements

During high volatility, stale prices lasting up to 72 hours can lead to significant mispricing of collateral. Conversely, if oracle infrastructure temporarily lags, the system may unnecessarily reject valid price data, causing denial-of-service conditions for legitimate operations.


Risk

Stability Risk: In volatile markets, accepting price data up to 72 hours old can result in liquidations at incorrect prices or failure to liquidate undercollateralized positions.​

Availability Risk: The fixed timeout cannot accommodate temporary oracle delays, potentially causing protocol lockup during periods when price updates are slightly delayed but still reasonably accurate.

Inflexibility: Protocol upgrades or integration of assets with different oracle characteristics require code modifications rather than parameter adjustments.​

Remediation

Proof of Concept

N/A

Recommended Mitigation

Implement a configurable staleness threshold with volatility-adaptive logic:

# State variable allowing governance updates
timeout_duration: public(uint256)
​
@external
def update_timeout_threshold(new_timeout: uint256):
assert msg.sender == self.governance, "Unauthorized"
assert new_timeout >= MIN_TIMEOUT and new_timeout <= MAX_TIMEOUT, "Invalid range"
self.timeout_duration = new_timeout
log TimeoutUpdated(new_timeout)
​
# Optional: Dynamic adjustment based on volatility metrics
@internal
def get_adaptive_timeout(asset_volatility: uint256) -> uint256:
if asset_volatility > HIGH_VOLATILITY_THRESHOLD:
return self.timeout_duration / 2 # Require fresher data
return self.timeout_duration # Standard timeout
​
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 1 day ago
Submission Judgement Published
Validated
Assigned finding tags:

[M-01] The TIMEOUT is set as a fixed constant of 72 hours, which makes it inflexible in adapting to the market price.

## Description In this contract, the TIMEOUT is set as a fixed constant (72 hours, or 259200 seconds). This means that if the oracle price data is not updated within 72 hours, the data will be considered outdated, and the contract will trigger a revert. ## Vulnerability Details At this location in the code, <https://github.com/Cyfrin/2024-12-algo-ssstablecoinsss/blob/4cc3197b13f1db728fd6509cc1dcbfd7a2360179/src/oracle_lib.vy#L15> ```Solidity TIMEOUT: constant(uint256) = 72 * 3600 ``` the timeout is directly set to 72 hours. For an oracle, which cannot dynamically adjust the price updates, this is a suboptimal approach. ## Impact - Fixed Timeout: The TIMEOUT is hardcoded to 72 hours. In markets with frequent fluctuations or assets that require more frequent price updates, 72 hours might be too long. Conversely, if the timeout is too short, it could cause frequent errors due to the inability to update data in time, disrupting normal contract operations. - Non-adjustable Timeout: If the contract's requirements change (e.g., market conditions evolve or the protocol requires more flexibility), the fixed TIMEOUT cannot be dynamically adjusted, leading to potential mismatches with current needs. - Lack of Flexibility: The current timeout mechanism is static and cannot be adjusted based on market volatility or the frequency of oracle updates. In volatile markets, a shorter TIMEOUT might be necessary, while in stable markets, a longer timeout would be more appropriate. \##Tools Used Manual review ## Recommendations Introduce a dynamic price expiration mechanism that adjusts based on market conditions. Use volatility data (such as standard deviation or market price fluctuation) to dynamically adjust the timeout period. This can be achieved by monitoring market volatility and adjusting the TIMEOUT accordingly: ```Solidity # Monitor market volatility and dynamically adjust TIMEOUT @external def adjustTimeoutBasedOnVolatility(volatility: uint256): if volatility > HIGH_VOLATILITY_THRESHOLD: self.TIMEOUT = SHORTER_TIMEOUT # In high volatility, decrease TIMEOUT else: self.TIMEOUT = LONGER_TIMEOUT # In stable market, increase TIMEOUT log TimeoutAdjusted(self.TIMEOUT) ```

Support

FAQs

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

Give us feedback!