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

The TIMEOUT is set as a fixed constant of 72 hours, which makes it inflexible in adapting to the market price

aiada

Description

  • Normal: Oracle price freshness thresholds should match market volatility — 1–2 hours for most DeFi protocols. Different assets have different Chainlink heartbeat intervals.

  • Bug: oracle_lib.vy:15 hardcodes TIMEOUT = 72 * 3600 (72 hours). A 3-day-old price is used as if it were fresh, even though markets can move 20%+ in that window. The constant cannot be adjusted per asset or over time.

# src/oracle_lib.vy:15
TIMEOUT: constant(uint256) = 72 * 3600 #@> 72 hours — far too long, fixed and immutable
​
# src/oracle_lib.vy:47-48
seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice" #@> Only rejects prices older than 3 days

Risk

Likelihood:

  • Chainlink typically updates ETH/USD and BTC/USD every 1 hour (3600s heartbeat)

  • In volatile markets, a price even 2–4 hours old can diverge significantly from the current market price

  • The 72-hour threshold means the protocol accepts prices that may be up to 71 hours stale

Impact:

  • Healthy positions liquidated at stale prices (price dropped but oracle hasn't updated yet)

  • Underwater positions not liquidatable because stale price shows them as healthy

  • Protocol insolvency risk — stale collateral valuations lead to bad debt accumulation

  • Cannot be adjusted without contract redeployment (constant, not immutable)

Proof of Concept

The _stale_check_latest_round_data function in oracle_lib.vy:26-50:

def _stale_check_latest_round_data(price_price_address: address) -> (...):
# ... fetches latestRoundData from Chainlink ...
seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"
#@> TIMEOUT = 259200 seconds (3 days)
#@> Chainlink ETH/USD heartbeat = 3600 seconds (1 hour)
#@> Protocol accepts prices up to 72× older than Chainlink's update interval

A Chainlink feed that stops updating (deprecation, circuit breaker, network congestion) would not be detected for up to 3 days. During this window, all protocol operations use a severely stale price.

Recommended Mitigation

- TIMEOUT: constant(uint256) = 72 * 3600
+ TIMEOUT: constant(uint256) = 2 * 3600 # 2 hours — matches Chainlink heartbeat + buffer

For production, consider making the timeout configurable per price feed so each asset can use its own Chainlink heartbeat as the baseline.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 10 hours 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!