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

Oracle staleness timeout is 72 hours — the engine mints and liquidates against day-old prices, allowing positions that are insolvent the moment a fresh price lands

junzai

Summary

oracle_lib.vy accepts Chainlink data up to 72 hours old (TIMEOUT: constant(uint256) = 72 * 3600). The canonical OracleLib this code is ported from uses a 3-hour timeout, and the ETH/USD and BTC/USD Chainlink feeds have a 1-hour heartbeat. Every valuation, mint, redemption and liquidation in dsc_engine.vy goes through this check, so the protocol will happily operate for up to three days on a frozen price. If the market moves while the feed is stale (or a feed simply stops updating), users can mint DSC against a collateral value that no longer exists, and the resulting positions are already underwater when the next fresh price arrives — before any liquidator can act.

Vulnerability Details

In src/oracle_lib.vy:

TIMEOUT: constant(uint256) = 72 * 3600 # 259,200 seconds = 72 hours
...
seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"

Verified empirically (see PoC): round data stamped 71 hours ago is accepted by get_usd_value, and data stamped 73 hours ago is rejected — the acceptance window really is ~72 hours, 24x the canonical 3-hour timeout and 72x the feeds' heartbeat.

Impact

A user whose collateral feed has been frozen at $2,000 for 24 hours while the market price fell to $1,000 can still deposit 10 WETH and mint 10,000 DSC at a displayed health factor of exactly 1.0 (the engine counts $20,000 of collateral). When the fresh $1,000 price lands, the position's real health factor is 0.5 and the protocol holds $10,000 of collateral against 10,000 DSC of debt that was supposed to be 200% collateralized — $10,000 of the supply is effectively unbacked until liquidators absorb the loss, and liquidation itself was impossible during the stale window at the true price because the engine could not see it. The longer a feed stalls (up to 3 days), the larger the insolvency that can be manufactured permissionlessly.

Proof of Concept

Boa/pytest test (passes locally with mox test):

def test_poc_stale_price_24h_allows_max_mint_then_insolvent(dsce, dsc, weth, eth_usd, some_user):
eth_usd.updateAnswer(2000 * 10**8)
now_ts = eth_usd.latestTimestamp()
# Rewind the round timestamp by 24h: last price is 24 hours old.
eth_usd.updateRoundData(900, 2000 * 10**8, now_ts - 24 * 3600, now_ts - 24 * 3600)
​
with boa.env.prank(some_user):
weth.approve(dsce, to_wei(10, "ether"))
dsce.deposit_collateral_and_mint_dsc(weth, to_wei(10, "ether"), to_wei(10_000, "ether"))
assert dsc.balanceOf(some_user) == to_wei(10_000, "ether")
assert dsce.health_factor(some_user) == to_wei(1, "ether") # HF exactly 1.0 on stale price
​
eth_usd.updateAnswer(1000 * 10**8) # fresh, real price
assert dsce.health_factor(some_user) == to_wei(0.5, "ether") # instantly insolvent-grade
​
def test_poc_staleness_window_is_72_hours(dsce, weth, eth_usd):
eth_usd.updateAnswer(2000 * 10**8)
now_ts = eth_usd.latestTimestamp()
eth_usd.updateRoundData(900, 2000 * 10**8, now_ts - 71 * 3600, now_ts - 71 * 3600)
assert dsce.get_usd_value(weth, to_wei(1, "ether")) == to_wei(2_000, "ether") # 71h: accepted
eth_usd.updateRoundData(901, 2000 * 10**8, now_ts - 73 * 3600, now_ts - 73 * 3600)
with boa.reverts("DSCEngine_StalePrice"):
dsce.get_usd_value(weth, to_wei(1, "ether")) # 73h: rejected -> window is ~72h

Recommended Mitigation

Reduce TIMEOUT to a value aligned with the feeds' heartbeat and the canonical library — 3 hours (3 * 3600) at most for ETH/USD and BTC/USD. The stale check should freeze the protocol shortly after a feed stops updating, not three days later.

Updates

Lead Judging Commences

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