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

Oracle staleness TIMEOUT is 72 hours instead of ~3, so the stale-price check accepts feeds frozen for up to 3 days

bytethebuilder

Root + Impact

Description

oracle_lib.vy is the protocol's defense against stale Chainlink prices: its docstring says to use the feed heartbeat to decide staleness and to freeze the DSCEngine if prices go stale. But the timeout is set far too high:

@> TIMEOUT: constant(uint256) = 72 * 3600 # 72 hours (= 259200s); canonical DSC uses 3 hours
​
seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"

Chainlink USD price feeds have heartbeats on the order of 1 hour (e.g. ETH/USD) up to 24 hours. A TIMEOUT of 72 hours is roughly 3-72x the actual heartbeat, so the staleness check is effectively defeated: a feed that has stopped updating for nearly 3 days still passes as "fresh." Every consumer of the price (_get_usd_value, _get_token_amount_from_usd) - and therefore collateral valuation, health-factor checks, minting, and liquidations - operates on prices that may be up to 3 days out of date.

During a stale window with real market movement, this mis-values collateral: a position that is actually undercollateralized still reads as healthy (so the owner can mint more DSC or avoid liquidation), and liquidations are computed against a wrong price (unfair seizures or missed liquidations leading to bad debt). The whole point of the stale-check - freezing the system when the oracle is unreliable - is neutralized.

Risk

Likelihood: Medium - Chainlink feeds do pause/lag (outages, low-volatility feeds with long heartbeats); any stall between the real heartbeat and 72h slips through.

Impact: Medium - the protocol prices collateral on stale data, enabling undercollateralized mints and incorrect/unfair liquidations (bad debt / user loss). It silently disables the intended oracle safety freeze.

Proof of Concept

A price that is 70 hours old is still accepted (no DSCEngine_StalePrice revert), proving the window is far wider than any feed heartbeat. Runnable titanoboa/pytest test (add to tests/unit/test_dsc_engine.py):

import boa
from eth_utils import to_wei
​
def test_PoC_stale_price_accepted_due_to_72h_timeout(dsce, weth):
# the eth/usd mock was last updated at deployment time; advance 70 hours
boa.env.time_travel(seconds=70 * 3600)
​
# With the canonical 3-hour TIMEOUT this MUST revert ("DSCEngine_StalePrice").
# With TIMEOUT = 72h, a 70-hour-old price is treated as fresh and the engine
# happily values collateral on it:
value = dsce.get_usd_value(weth, to_wei(1, "ether"))
assert value > 0 # no revert -> stale (70h-old) price accepted

Run moccasin test (or pytest); the call does not revert, demonstrating the engine reads a 70-hour-stale price as valid. (With TIMEOUT = 3 * 3600 the same call reverts with DSCEngine_StalePrice.)

Recommended Mitigation

Set TIMEOUT to match the actual Chainlink heartbeat of the feeds in use (the canonical DSC value is 3 hours), or store a per-feed heartbeat and check against it, so genuinely stale data freezes the protocol as intended:

- TIMEOUT: constant(uint256) = 72 * 3600
+ TIMEOUT: constant(uint256) = 3 * 3600 # align with the feed heartbeat (e.g. ETH/USD ~1h, use a small safety margin)

For a multi-feed deployment where heartbeats differ, prefer a per-feed configurable heartbeat rather than one global constant, and keep the revert-on-stale behavior so the engine safely freezes when any required feed is stale.

Updates

Lead Judging Commences

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