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

Oracle staleness TIMEOUT of 72 hours makes the stale-price protection ineffective

mohsinarif84

Root + Impact

Description

The protocol prices all collateral exclusively through Chainlink price feeds. To protect users, oracle_lib is designed to detect when a feed has gone stale (stopped updating) and revert, freezing the engine rather than acting on an outdated price. Its own documentation states the intent clearly: "We should use the Chainlink feed heartbeat to determine if a feed is stale or not." A feed's heartbeat is the maximum interval Chainlink guarantees between updates (for ETH/USD and BTC/USD on mainnet this is roughly 1 hour); a price older than that heartbeat (plus a small buffer) should be treated as stale.

The specific problem is that TIMEOUT is set to 72 hours, dozens of times larger than the feeds' actual heartbeat. As a result, _stale_check_latest_round_data accepts any price that is up to 3 days old as if it were fresh. The staleness protection the library is supposed to provide is therefore effectively disabled for every realistic feed outage or delay.

@> TIMEOUT: constant(uint256) = 72 * 3600 # 72 hours; ~72x the real ~1h feed heartbeat
...
seconds_since: uint256 = block.timestamp - updated_at
@> assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice" # only reverts after a full 3 days

Risk

Likelihood:

  • A Chainlink feed stops updating for longer than its ~1h heartbeat but less than 72 hours — a routine, repeatedly-observed condition (feed operator issues, network congestion, a deprecated/paused feed), not an exotic edge case.

  • No attacker action is required to reach the vulnerable state; it is reached automatically whenever a feed stalls, and anyone can then interact with the protocol while the stale price is still served.

Impact:

  • All collateral valuation (_get_usd_value, health_factor, liquidations) runs off a price that may be up to 3 days out of date, during which ETH/BTC can move tens of percent.

  • If the stale price is higher than reality, users mint_dsc against over-valued collateral, creating undercollateralized debt — a direct path to insolvency and loss of the DSC peg.

  • If the stale price is lower than reality, healthy users are wrongfully liquidated, losing collateral plus the 10% liquidation bonus.

Proof of Concept

Explanation: The check only compares the age of the price to a 3-day window, so a feed stale by less than 3 days silently passes and the protocol keeps using the old price. The test below deploys a mock Chainlink feed reporting $3,000, advances time by 48 hours (far past a ~1h heartbeat), and shows that the staleness check does not revert and returns the stale price:

import boa
​
def test_72h_timeout_accepts_a_48h_stale_price():
# Mock Chainlink feed: 8 decimals, price = $3000, updatedAt = now
mock_feed = boa.load("src/mocks/MockV3Aggregator.vy", 8, 3000 * 10**8)
oracle = boa.load("src/oracle_lib.vy")
​
# The feed has not updated for 48 hours (a realistic stall, ~47h past the ~1h heartbeat)
boa.env.time_travel(seconds=48 * 3600)
​
# SAFE behavior would be to revert with "DSCEngine_StalePrice".
# ACTUAL behavior: it returns the 48h-old price with no revert, because
# seconds_since = 48*3600 = 172_800 <= TIMEOUT = 72*3600 = 259_200
round_id, price, started_at, updated_at, answered_in_round = \
oracle.stale_check_latest_round_data(mock_feed.address)
​
assert price == 3000 * 10**8 # stale price served; staleness guard never triggered -> BUG

Running this passes, proving a 48-hour-old price is accepted. The engine then prices all collateral off that stale value until the feed is 3 full days old.

Recommended Mitigation

Explanation: TIMEOUT must reflect the heartbeat of the specific feed being read (plus a small safety buffer), not an arbitrary multi-day constant. For ETH/USD and BTC/USD (~1h heartbeat), ~3 hours is appropriate. Because feeds can differ, the most robust fix stores a per-feed timeout; at minimum, reduce the global constant to match the real heartbeat:

- TIMEOUT: constant(uint256) = 72 * 3600
+ TIMEOUT: constant(uint256) = 3 * 3600 # align to the feed heartbeat (+ buffer); use per-feed timeouts if feeds differ
Updates

Lead Judging Commences

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