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

[M-01] 72-Hour Oracle Timeout Is Too Long for Volatile Assets

rensley

Root + Impact

Description

  • The TIMEOUT constant in oracle_lib.vy is set to 72 hours (259,200 seconds). For volatile assets like ETH and BTC, this timeout is far too long.

  • Chainlink's ETH/USD feed has a heartbeat of 1 hour, meaning prices can be up to 72x more stale than expected.

  • During high volatility, a 72-hour-old price could be completely disconnected from reality, enabling undercollateralized positions or preventing legitimate liquidations.

// Root cause in the codebase with @> marks to highlight the relevant section
​
@> TIMEOUT: constant(uint256) = 72 * 3600 # 72 hours - too long!
​

Risk

Likelihood: Medium

  • Reason 1 // Market volatility is common in crypto

  • Reason 2 // Oracle delays happen during network congestion

Impact: High

  • Impact 1 // Stale prices allow undercollateralized minting

  • Impact 2 // Liquidations may not trigger when needed

  • Impact 3 // Protocol can become insolvent during crashes

Proof of Concept

The following scenario demonstrates how stale prices during a market crash can leave the protocol with bad debt. A 72-hour-old price during a 50% crash means positions are dangerously undercollateralized but the system doesn't recognize it.

def test_stale_price_during_crash():
# Price was $2000 72 hours ago
# Current real price is $1000 (50% crash)
# But oracle hasn't updated
with boa.env.prank(user):
# User deposits based on stale $2000 price
weth.approve(dsce, COLLATERAL_AMOUNT)
dsce.deposit_collateral_and_mint_dsc(weth, COLLATERAL_AMOUNT, AMOUNT_TO_MINT)
# Position is actually undercollateralized at real $1000 price
# But system thinks it's healthy based on stale price
health_factor = dsce.health_factor(user)
assert health_factor >= MIN_HEALTH_FACTOR # Appears healthy
# When price finally updates, position is deeply underwater
# Bad debt accumulates in the system

Recommended Mitigation

Reduce the timeout to match Chainlink's heartbeat for the specific feed. For ETH/USD and BTC/USD, a timeout of 1-2 hours is more appropriate and aligns with Chainlink's actual update frequency.

- TIMEOUT: constant(uint256) = 72 * 3600 # 72 hours
+ TIMEOUT: constant(uint256) = 1 * 3600 # 1 hours - matches Chainlink 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!