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

72-Hour Oracle Timeout Allows Severely Stale Prices

vikramgoutham289

Root + Impact

Root Cause: The oracle_lib.vy uses a hardcoded 72-hour timeout for price staleness checks, while Chainlink ETH/USD and BTC/USD feeds have a 1-hour heartbeat.

Impact: Prices can be up to 3 days old before being rejected. During volatile markets, this allows users to mint excess DSC using inflated stale prices or avoid liquidation when prices have dropped significantly, leading to protocol undercollateralization.

Description

Normal Behavior: The oracle should provide current market prices to accurately value collateral. Chainlink ETH/USD and BTC/USD feeds have a 1-hour heartbeat.

Issue: The oracle_lib.vy uses a 72-hour timeout, meaning prices can be up to 3 days old before being considered stale. This far exceeds the actual heartbeat of the price feeds.
# oracle_lib.vy
TIMEOUT: constant(uint256) = 72 * 3600 # @> 72 hours = 259,200 seconds
​
@internal
@view
def _stale_check_latest_round_data(price_price_address: address) -> (...):
# ...
seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice" # @> Allows 72-hour-old prices
# ...

Risk

Likelihood:Medium

  • Reason 1 : Every time the oracle hasn't updated in 1-72 hours, stale prices are used

  • Reason 2 : During network congestion or Chainlink issues, updates may be delayed

Impact:

  • Impact 1 : Liquidations don't trigger when they should due to stale high prices

  • Impact 2 : Users mint excess DSC using inflated stale prices

Proof of Concept

At T+0, the oracle updates ETH price to $2000. Over 24 hours, ETH actually drops 40% to $1200, but the oracle hasn't updated due to network congestion. The system still uses the $2000 stale price because it's within the 72-hour timeout. An attacker deposits 1 ETH, receives $2000 credit, and mints $900 DSC. When the oracle updates, their true collateralization is only 133%, creating $300 of bad debt.

def test_stale_price_exploitation():
# Timeline:
# T+0h: ETH = $2000, Oracle updates
# T+24h: ETH actual = $1200 (40% crash), Oracle hasn't updated (network congestion)
# T+24h: System still uses $2000 price (within 72h timeout)
# Attack:
# 1. Attacker deposits 1 ETH
# 2. System values at $2000 (stale price)
# 3. Attacker mints 900 DSC (200% collateralization at stale price)
# 4. Oracle updates to $1200
# 5. True collateralization: $1200 / $900 = 133% (severely undercollateralized)
# Result:
# - $300 of bad debt per ETH deposited during stale window
# - At scale, millions in protocol losses

Recommended Mitigation

Reduce the timeout to match the actual heartbeat of the supported price feeds. For ETH/USD and BTC/USD, a 1-hour timeout is appropriate. This ensures prices are never significantly stale relative to the oracle's update frequency.

# oracle_lib.vy
​
- TIMEOUT: constant(uint256) = 72 * 3600 # 72 hours
+ TIMEOUT: constant(uint256) = 3600 # 1 hour - matches ETH/USD and BTC/USD heartbeat
Updates

Lead Judging Commences

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