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

Oracle stale-price timeout is 72 hours, so collateral is valued and liquidated using prices up to 3 days old

niosoke

Root + Impact

The stale-price guard that every price read in the DSCEngine depends on accepts Chainlink answers that are up to 72 hours old. The ETH/USD and BTC/USD feeds used by this protocol have a 1-hour heartbeat, and the canonical DSCEngine OracleLib this codebase is ported from uses a 3-hour timeout. With a 72-hour window, the engine keeps minting, redeeming and liquidating at prices that can be three days out of date, so during any feed stall or fast market move users can mint underbacked DSC at the old price and liquidations are settled at the wrong price.

Description

src/oracle_lib.vy sets the timeout to 3 days, and DSCEngine._get_usd_value / _get_token_amount_from_usd (used by health factor, minting, redemption and liquidation) rely on this check as their only freshness protection:

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

The library's own docstring says the timeout should follow the Chainlink feed heartbeat ("We should use the Chainlink feed heartbeat to determine if a feed is stale or not"). The heartbeat of both collateral feeds is 1 hour, so a 72-hour timeout accepts answers 72 heartbeats late.

Risk

Likelihood: Medium - requires a feed stall or a sharp move between updates, but the window is 72x wider than the feeds' heartbeat, and zkSync Era feeds have stalled before.
Impact: Medium - minting and liquidation decisions are made on materially wrong prices for up to 3 days: underbacked DSC can be minted after a collateral crash, and liquidators are paid out at stale valuations, both of which push the system toward insolvency (which the README itself lists as unrecoverable).

Proof of Concept

Executed locally with titanoboa against the in-scope contracts and MockV3Aggregator: after setting the ETH feed's updated_at 71 hours into the past, DSCEngine.get_usd_value still returns the full $2,000 valuation instead of reverting. Only at 73 hours does the stale check finally revert, confirming the effective timeout is 72 hours.

round_id, price, started_at, updated_at, answered = eth_feed.latestRoundData()
eth_feed.updateRoundData(round_id, price, updated_at - 71 * 3600, updated_at - 71 * 3600)
value = engine.get_usd_value(weth.address, 10**18)
assert value > 0 # 71-hour-old price accepted: returns 2000 * 10**18
​
eth_feed.updateRoundData(round_id, price, updated_at - 73 * 3600, updated_at - 73 * 3600)
# engine.get_usd_value(...) now reverts with DSCEngine_StalePrice

Recommended Mitigation

Bring the timeout in line with the feeds' heartbeat and the canonical OracleLib (3 hours), or store a per-feed timeout:

-TIMEOUT: constant(uint256) = 72 * 3600
+TIMEOUT: constant(uint256) = 3 * 3600
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!