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

Finding: Stale price check uses a fixed 72-hour TIMEOUT instead of the feed's heartbeat

sleepycat12341013

Root + Impact

Description

  • oracle_lib.vy uses a fixed value, TIMEOUT = 72 * 3600 (72 hours), to check price freshness (line 19; the check itself is at line 52). However, the heartbeat of the Chainlink ETH/USD feed is 1 hour, so a healthy feed updates at least once every hour.

    This means the code accepts a price up to 72 hours old as fresh, even though a price older than 1 hour is already abnormal. Moreover, the docstring itself says "We should use the Chainlink feed heartbeat", so the implementation contradicts its own comment.

# oracle_lib.vy
@> TIMEOUT: constant(uint256) = 72 * 3600 # fixed 72h, ignores the feed's 1h heartbeat
​
# ... in _stale_check_latest_round_data():
seconds_since: uint256 = block.timestamp - updated_at
@> assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice" # accepts prices up to 72h old

Risk

Likelihood:

  • Reason 1 // Describe WHEN this will occur (avoid using "if" statements)

  • Reason 2

Impact:

  • Collateral is valued with a price up to 72 hours old. Even if the real collateral value crashes, the health factor is still judged healthy based on the stale price (e.g., $3,000), so liquidations that should happen are missed. Delayed liquidations push the protocol toward insolvency.

Proof of Concept

import boa
from eth_utils import to_wei
​
from tests.conftest import AMOUNT_TO_MINT, COLLATERAL_AMOUNT
​
​
def test_71_hour_old_price_is_accepted_as_fresh(dsce, some_user, weth):
# A user deposits collateral and mints DSC while the price is fresh.
with boa.env.prank(some_user):
weth.approve(dsce.address, COLLATERAL_AMOUNT)
dsce.deposit_collateral_and_mint_dsc(
weth.address, COLLATERAL_AMOUNT, AMOUNT_TO_MINT
)
​
# The mock ETH/USD feed was last updated at deployment. Travel 71 hours
# into the future WITHOUT any feed update. The real ETH/USD feed has a
# 1-hour heartbeat, so this price is now stale ~70x over. The docstring
# says the protocol should freeze ("functions will revert") on stale data.
boa.env.time_travel(seconds=71 * 3600)
​
# Expected: revert with "DSCEngine_StalePrice"
# Actual: both calls succeed — the 71-hour-old price is still used to
# value collateral and compute the health factor, so a user whose real
# collateral value has crashed during those 71 hours cannot be liquidated.
usd_value = dsce.get_usd_value(weth.address, to_wei(1, "ether"))
assert usd_value > 0 # stale price accepted, no revert
​
health = dsce.health_factor(some_user)
assert health > 0 # health factor still computed from the stale price
```
​
Running this test shows both calls pass; with a heartbeat-based timeout (e.g. 3600 + margin), both would revert with `DSCEngine_StalePrice` as the docstring intends.

Recommended Mitigation

・Set the TIMEOUT based on each feed's heartbeat, instead of the fixed 72 hours (e.g., 1 hour plus a margin for ETH/USD). Since the heartbeat varies from feed to feed, the TIMEOUT should be configurable per feed.

diff
- TIMEOUT: constant(uint256) = 72 * 3600
+ # Per-feed timeout, set to the feed's heartbeat plus a safety margin
+ # (e.g., ETH/USD: 1 hour heartbeat -> 3600 + margin)
+ timeouts: public(HashMap[address, uint256])
​
seconds_since: uint256 = block.timestamp - updated_at
- assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"
+ assert seconds_since <= self.timeouts[price_price_address], "DSCEngine_StalePrice"
Updates

Lead Judging Commences

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