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

A fixed 72-hour timeout accepts stale prices long after the feeds 24-hour heartbeat

rvoffindings

Root + Impact

Description

oracle_lib uses one global, immutable 72-hour timeout for every collateral feed:

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

The ETH/USD and BTC/USD feeds used by this challenge have a 24-hour (86,400 second) heartbeat. Once that heartbeat has elapsed, the feed has already missed its expected update guarantee, but the protocol continues accepting the old answer until 259,200 seconds. This creates a 48-hour window in which stale prices flow into get_usd_value(), health-factor checks, minting, redemption, and liquidation.

During an oracle delay combined with a market decline, an attacker can deposit collateral and mint DSC against the older, higher price. Existing unhealthy positions may also avoid liquidation because their stale collateral value remains inflated. Either path can leave DSC undercollateralized.

Risk

Likelihood: Medium

  • Exploitation requires the price feed to miss its update and a meaningful market move during the stale window.

  • Once those conditions occur, all public economic entrypoints automatically consume the stale value for up to two additional days.

Impact: High

  • A stale high price can authorize excess DSC minting or delay liquidation.

  • The resulting debt can exceed the real collateral value and threaten protocol solvency and the DSC peg.

The combined High impact and Medium likelihood support a Medium severity rating.

Proof of Concept

This Titanoboa test deploys the exact scoped contracts with the repository MockV3Aggregator. The price remains accepted one second after the feed's 24-hour heartbeat has expired and only reverts after the full 72-hour protocol timeout.

def test_feed_is_accepted_after_its_24_hour_heartbeat_has_expired():
_, engine, _, weth, _, _ = deploy_system()
​
expected = 2_000 * 10**18
assert engine.get_usd_value(weth.address, 10**18) == expected
​
boa.env.time_travel(seconds=24 * 3600 + 1)
​
# Already beyond the feed heartbeat, but still accepted by oracle_lib.
assert engine.get_usd_value(weth.address, 10**18) == expected
​
boa.env.time_travel(seconds=48 * 3600)
with boa.reverts("DSCEngine_StalePrice"):
engine.get_usd_value(weth.address, 10**18)

Observed result: PASS. The first call at an age of 86,401 seconds succeeds; rejection only occurs after the total age exceeds 259,200 seconds.

Recommended Mitigation

Associate a maximum delay with each price feed and align it with that feed's documented heartbeat. For both feeds in this challenge, reject data older than 86,400 seconds:

-TIMEOUT: constant(uint256) = 72 * 3600
+ETH_USD_MAX_DELAY: constant(uint256) = 24 * 3600
+BTC_USD_MAX_DELAY: constant(uint256) = 24 * 3600

A per-feed immutable mapping is preferable when collateral feeds may have different heartbeats. The check should use the selected feed's max delay, and tests must cover the exact boundary: 86,400 seconds accepted (if inclusive) and 86,401 seconds rejected. Mint, redeem, and liquidation tests should all prove that stale prices are propagated as a revert.

Updates

Lead Judging Commences

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