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

Hardcoded `TIMEOUT` Is too long relative to feed heartbeat

s3mvl4d

Description

  • The oracle library checks whether Chainlink price data is fresh by comparing the feed’s updatedAt timestamp to a timeout threshold. If the data is older than the timeout, the function should revert to prevent stale price usage.

  • The contract defines TIMEOUT as a constant set to 259,200 seconds (72 hours). However, the Chainlink ETH/USD and BTC/USD feeds used by the protocol have a heartbeat of 86,400 seconds (24 hours). Because the contract timeout is 3× longer than the real heartbeat, the protocol considers stale oracle data “valid” for up to 72 hours, even though Chainlink guarantees freshness only within 24 hours. Furthermore, because TIMEOUT is a constant, the protocol cannot change this value without redeploying the library.

# Root cause: TIMEOUT is a constant, set too high and cannot be changed
@> TIMEOUT: constant(uint256) = 72 * 3600
​
seconds_since: uint256 = block.timestamp - updated_at
@> assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"

Risk

Likelihood: High

  • Chainlink ETH/USD and BTC/USD feeds update hourly, but their guaranteed heartbeat is 24 hours. Because the protocol uses a 72‑hour timeout, stale data frequently passes validation.

  • Any oracle outage shorter than 72 hours will not freeze the system, even though it should under the intended design.

Impact: Medium

  • Stale price acceptance — The protocol may perform minting, redeeming, liquidations, or collateral valuations using 48–72h‑old prices.

  • Incorrect valuations — In volatile markets, stale prices can cause insolvency, unfair liquidations, or mis‑priced collateral calculations.

Proof of Concept

Scenario: Chainlink feed stops updating for 30 hours

  • Chainlink heartbeat = 24h

  • TIMEOUT = 72h

Price feed stops at timestamp T. At time T + 30h, the protocol checks price freshness:

➡ Bug: Price 30 hours old is considered fresh (even though Chainlink only guarantees freshness for up to 24 hours).
➡ The protocol continues to operate with stale price data.

// Assume price feed updated 30 hours ago
uint256 updatedAt = block.timestamp - 30 hours;
​
// TIMEOUT is incorrectly fixed at 72 hours
uint256 TIMEOUT = 72 hours;
​
// This condition incorrectly passes
assert(block.timestamp - updatedAt <= TIMEOUT);
// No revert, stale price is used

Recommended Mitigation

  • Replace constant timeout with configurable storage variable

  • Add governance‑controlled setter

​
- TIMEOUT: constant(uint256) = 72 * 3600
+ timeout: public(uint256) # can be set via governance
​
​
@external
def set_timeout(new_timeout: uint256):
assert msg.sender == self.owner
self.timeout = new_timeout
​
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 14 days 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!