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

M01. Excessive oracle staleness timeout

adcdiii

Root + Impact

Description

  • Normal behavior: Oracle staleness checks should reject prices that are older than a short, clearly defined threshold in line with Chainlink’s heartbeat for each feed (typically around 1 hour for major pairs).

  • Issue: The protocol uses a 72‑hour timeout (TIMEOUT = 72 * 3600), allowing extremely stale prices to be treated as fresh, enabling minting or preventing liquidation based on outdated valuations.

// oracle_lib.vy (conceptual)
TIMEOUT: constant(uint256) = 72 * 3600 # @> 72 hours
​
@internal
@view
def _stale_check_latest_round_data(price_feed: address) -> ...:
(round_id, price, started_at, updated_at, answered_in_round) = price_feed.latestRoundData()
seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"

Risk

Likelihood:

  • Reason 1 // Network congestion, oracle network incidents, or L2 delays can cause price updates to pause for shorter periods (minutes to hours) but are unlikely to justify a 72‑hour acceptance window.

  • Reason 2 // In volatile markets, price changes over even a few hours can be large enough to materially affect collateralization.

Impact:

  • Impact 1 // Users can mint additional DSC or avoid liquidation based on prices that are up to three days old, creating unbacked debt and inaccurate health factors.

  • Impact 2 // Attackers can combine staleness with market movements to exploit mispriced collateral, especially if the off‑chain price falls significantly while the on‑chain feed remains stuck.

Proof of Concept

Using a mock feed that stops updating, the system continues accepting old prices:

  1. The mock Chainlink feed is set to update once, then stop.

  2. The protocol continues to call _stale_check_latest_round_data, which accepts the old updated_at for up to 72 hours.

  3. Over this period, the real market price drops sharply, but users continue to mint DSC at the old, inflated price.

function testStaleOracleStillAcceptedFor72Hours() public {
// Set initial price
setPrice(address(weth), 2000e18);
uint256 lastUpdated = block.timestamp;
​
// Advance time by, e.g., 48 hours
vm.warp(lastUpdated + 48 hours);
​
// @> With TIMEOUT = 72 hours, this is still accepted
// Minting and collateral checks wrongly use a 2-day-old price
engine.deposit_collateral(address(weth), 1 ether);
engine.mint_dsc(allowedByOldPrice());
}

Recommended Mitigation

Reduce the timeout to a much shorter value and ideally make it configurable per feed.

// oracle_lib.vy
- TIMEOUT: constant(uint256) = 72 * 3600
+ TIMEOUT: constant(uint256) = 3 * 3600 # example 3 hours
​
# or per-feed timeout via storage if needed
Updates

Lead Judging Commences

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