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

72-hour oracle timeout allows protocol to operate on severely stale prices

r0p

Title: 72-hour oracle timeout allows protocol to operate on severely stale prices
Severity: Medium
Impact: Protocol may accumulate undercollateralized debt during prolonged oracle outages.
Likelihood: Medium — requires Chainlink feed disruption exceeding 24 hours but under 72 hours.
Reference Files: src/oracle_lib.vy:15,47-48

Description

The oracle staleness check uses a hardcoded 72-hour timeout — three times the Chainlink heartbeat for ETH/USD and BTC/USD (86400s = 24 hours). The protocol accepts deposits and mints DSC against prices up to 3 days old, making it possible to operate on data that missed two complete heartbeat cycles. The vulnerable code:

TIMEOUT: constant(uint256) = 72 * 3600
​
seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"

A 72-hour window means the oracle can stop updating for 71 hours while the protocol continues processing deposits, mints, redemptions, and liquidations against frozen prices.

Risk

Impact: Medium. If Chainlink stops updating and the market moves significantly during the 72-hour window, users can deposit overvalued collateral and mint DSC at favorable rates. When the oracle resumes, the protocol may hold more DSC debt than the collateral is worth, pushing it toward insolvency.
Likelihood: Medium. Chainlink feeds self-recover within their 86400s heartbeat under normal operation. A multi-hour feed stall is rare but has occurred historically during network congestion events.
During the March 2020 ETH crash ($200 → $90 in 24 hours), a 72-hour timeout would have allowed 48 hours of operations on stale $200 prices while ETH traded at $90 — each deposited ETH would secure $200 of DSC against $90 of actual value.

Proof of Concept

import boa
from eth_utils import to_wei
​
# Deploy mock with manipulated oracle timestamps
def test_stale_price_exploit():
# 1. Normal operation: oracle updates at t=0 with ETH=$2000
eth_usd.updateAnswer(2000 * 10**8)
# 2. User deposits 10 ETH and mints 10,000 DSC at $2000/ETH
dsce.deposit_collateral_and_mint_dsc(weth, to_wei(10, "ether"), to_wei(10_000, "ether"))
# 3. Chainlink feed stalls for 48 hours. ETH crashes to $1000.
# But because TIMEOUT=72h, the stale $2000 price is still considered valid.
boa.env.time_travel(48 * 3600) # +48 hours
eth_usd.updateAnswer(1000 * 10**8) # Would update if feed wasn't stalled
# 4. At the stalled feed, ETH still valued at $2000.
# User withdraws 5 ETH — protocol sees it as $10,000 collateral reduction.
# Real value: only $5,000 worth.
dsce.redeem_collateral(weth, to_wei(5, "ether"))
# 5. Protocol now has $5,000 real collateral backing $10,000 DSC.
# At 50% LTV, this should have reverted as undercollateralized.
# Instead: user got $5,000 real ETH out for free, DSC is underbacked.

This test demonstrates that a 48-hour feed stall (well within the 72h TIMEOUT) allows users to extract real value against stale prices, leaving the protocol undercollateralized by $5,000 per 5 ETH withdrawn. At protocol scale with millions in TVL, the insolvency gap could reach hundreds of thousands.

Recommended Mitigation

TIMEOUT: constant(uint256) = 4 * 3600 # 4 hours

Reducing the timeout to 4 hours ensures the protocol freezes shortly after the Chainlink heartbeat is missed. Chainlink's 86400s heartbeat provides a reasonable worst-case update interval; a 4-hour buffer (14400s) after the expected 24-hour update catches feed stalls before significant market movement can occur. The protocol then reverts all price-dependent operations until the oracle recovers, preserving solvency.

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!