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

72-Hour Oracle Staleness Window

lordbolton

Root + Impact

The oracle_lib.vy uses a 72-hour staleness timeout, allowing the protocol to accept 3-day-old prices during oracle outages. Users mint DSC against overvalued collateral when real prices crash, creating protocol insolvency.

Description

  • The protocol checks Chainlink price freshness by comparing block.timestamp - updated_at against a TIMEOUT threshold before accepting prices.

  • The TIMEOUT is set to 72 hours (259,200 seconds), allowing the protocol to operate on stale prices that overvalue collateral for up to 3 days during market crashes.

# 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) -> (uint80, int256, uint256, uint256, uint80):
# ... code ...
seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice" # @> Accepts prices up to 72 hours old
return (round_id, price, started_at, updated_at, answered_in_round)

Risk

Likelihood:

  • Chainlink oracles experience periodic outages or delayed updates due to network congestion or infrastructure issues.

  • Crypto asset prices frequently move 20-50% within 24 hours during high volatility events.

Impact:

  • Users mint DSC against collateral valued at stale inflated prices, creating undercollateralized positions.

  • Protocol becomes insolvent as total DSC supply exceeds actual collateral value, with bad debt accumulating for up to 72 hours.

Proof of Concept

# T=0: User deposits 10 ETH @ $2,000 = $20,000, mints 10,000 DSC (50% ratio), HF = 1.0
​
# T+24h: Oracle stops updating, real ETH crashes to $1,000
# Staleness check: 86,400s <= 259,200s → PASSES ✅
# Protocol thinks: $20,000 collateral, HF = 1.0 ✅
# Reality: $10,000 collateral, HF = 0.5 ❌ (LIQUIDATABLE)
​
# T+48h: Attacker deposits 10 ETH (real value $10,000)
# Protocol values at $20,000 (stale price)
# Mints 10,000 DSC (should only mint $5,000 at 50% ratio)
# Profit: $5,000 in unbacked DSC
​
with boa.env.prank(some_user):
weth.approve(dsce, to_wei(10, "ether"))
dsce.deposit_collateral(weth, to_wei(10, "ether"))
collateral_value = dsce.get_usd_value(weth, to_wei(10, "ether")) # Returns $20,000 (stale)
max_dsc = (collateral_value * 50) // 100
dsce.mint_dsc(max_dsc) # Mints 10,000 DSC against $10,000 real value

Recommended Mitigation

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

Lead Judging Commences

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