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

Oracle Staleness Timeout of 72 Hours Allows Severely Stale Prices

quanghoa27061998

Oracle Staleness Timeout of 72 Hours Allows Severely Stale Prices

Description

The TIMEOUT constant in oracle_lib.vy is set to 72 hours (259,200 seconds):

TIMEOUT: constant(uint256) = 72 * 3600

This is used as the maximum acceptable age for Chainlink price data:

seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"

Chainlink's WETH/USD and WBTC/USD price feeds have a heartbeat of approximately 1 hour on Ethereum mainnet and may vary on ZKsync Era. A 72-hour timeout means the protocol accepts price data that could be up to 3 days old.

Risk

Likelihood: Medium -- During periods of Chainlink oracle degradation or network congestion, price feeds can delay updates. The 72-hour window is also exploitable during normal market conditions if a feed's heartbeat is missed.

Impact: High -- During a 72-hour window, ETH and BTC prices can move 30-50% in volatile markets. With stale (higher) prices:

  • Attackers can mint more DSC than their collateral warrants at current prices

  • Positions that should be liquidatable remain "healthy" per the stale price

  • Liquidators execute at wrong prices, receiving too much or too little collateral

Real-World Precedent:

  • Compound DAI Liquidation (2020): Stale oracle manipulation caused $89M in unfair liquidations

  • Mango Markets (2022): Oracle price manipulation caused $114M loss

Proof of Concept

How the attack works:

  1. ETH price is $2,000 at time T. Oracle reports$2,000.

  2. Attacker deposits 10 ETH ($20,000 at$2,000) and mints 10,000 DSC (200% collateralization)

  3. ETH crashes to $1,200 over 24 hours, but oracle feed is delayed (e.g., ZKsync sequencer issues)

  4. With stale price, attacker's health factor remains above 1.0, preventing liquidation

  5. Attacker can even mint MORE DSC against the stale $2,000 valuation

  6. After the oracle finally updates to $1,200, the position is deeply underwater ($12,000 collateral vs $10,000+ debt)

Expected outcome: Protocol holds bad debt as positions minted during stale-price windows are underwater when prices update.

def test_attacker_mints_with_stale_high_price(self, dsce, weth, eth_usd, dsc, some_user):
current_ts = eth_usd.latestTimestamp()
current_round = eth_usd.latestRound()
​
# Oracle stuck at $2,000 from 50 hours ago (still within 72h TIMEOUT)
stale_ts = current_ts - (50 * 3600)
eth_usd.updateRoundData(current_round + 1, 2000 * 10**8, stale_ts, stale_ts)
​
# Mint max DSC at stale $2,000 price (10 ETH = $20,000 -> 10,000 DSC)
with boa.env.prank(some_user):
weth.approve(dsce.address, COLLATERAL_AMOUNT)
dsce.deposit_collateral_and_mint_dsc(
weth.address, COLLATERAL_AMOUNT, to_wei(10_000, "ether")
)
​
# Oracle updates to real price: $1,200
eth_usd.updateAnswer(1200 * 10**8)
​
# Position is now underwater: $12,000 collateral vs $10,000 debt
# Health factor = (12000 * 50/100) / 10000 = 0.6 < 1.0
assert dsce.health_factor(some_user) < to_wei(1, "ether")

Recommended Mitigation

Set the timeout to match the Chainlink heartbeat for the specific chain, with a reasonable buffer:

# For ZKsync Era, use appropriate heartbeat
# WETH/USD: ~1 hour heartbeat, WBTC/USD: ~1 hour heartbeat
# Use 3 hours (3x heartbeat) as a conservative buffer
TIMEOUT: constant(uint256) = 3 * 3600 # 3 hours instead of 72

For maximum correctness, consider per-feed staleness thresholds stored in the constructor:

token_address_to_timeout: HashMap[address, uint256]
Updates

Lead Judging Commences

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