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

Oracle accepts 72-hour-stale prices and never rejects a zero/negative price

wolzies

Root + Impact

Description

oracle_lib accepts Chainlink prices up to 72 hours old and never checks that the price is positive, so the engine can operate on a dangerously stale price and a zero/negative feed price bricks the protocol.

First, TIMEOUT is 72 hours, while the ETH/USD and BTC/USD feeds update roughly every hour — and the library's own notice says to use the feed heartbeat to judge staleness. During a crash, users can mint against a 71-hour-old high price, and the protocol only freezes after 72 hours.

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

Second, there is no price > 0 check. A zero feed price makes _get_usd_value return 0 for all collateral, and _get_token_amount_from_usd divides by zero, so every liquidation reverts and the protocol is bricked until the feed recovers. (A negative price reverts inside convert(price, uint256), with the same bricking effect.)

Risk

Likelihood: Medium — a stale feed requires a Chainlink outage or a market crash coinciding with an old price, but the 72-hour window is always open by design; a zero price requires a feed failure.

Impact: High — minting against a 3-day-old price lets users mint undercollateralized DSC (bad debt), and a zero/negative price freezes all oracle-dependent functions (minting, redemption, liquidation) protocol-wide.

Proof of Concept

The first two tests warp time forward and show a 71-hour-old price is still accepted while a 73-hour-old price reverts, pinning the window at 72 hours. The third test sets the feed answer to 0 and shows collateral valued at $0 and the liquidation math reverting with division by zero.

def test_M1_stale_price_71h_still_accepted(setup):
s = setup
boa.env.time_travel(71 * 3600)
with boa.env.prank(s["user"]):
s["weth"].approve(s["engine"], to_wei(10, "ether"))
s["engine"].deposit_collateral_and_mint_dsc(
s["weth"], to_wei(10, "ether"), to_wei(100, "ether")
)
assert s["dsc"].balanceOf(s["user"]) == to_wei(100, "ether")
​
def test_M1_stale_price_73h_reverts(setup):
s = setup
boa.env.time_travel(73 * 3600)
with boa.env.prank(s["user"]):
s["weth"].approve(s["engine"], to_wei(10, "ether"))
with boa.reverts("DSCEngine_StalePrice"):
s["engine"].deposit_collateral_and_mint_dsc(
s["weth"], to_wei(10, "ether"), to_wei(100, "ether")
)
​
def test_M1_zero_price_not_rejected(setup):
s = setup
s["eth_feed"].updateAnswer(0)
​
# All collateral is suddenly worth $0.
assert s["engine"].get_usd_value(s["weth"], to_wei(10, "ether")) == 0
​
# And any liquidation math divides by zero.
with boa.reverts():
s["engine"].get_token_amount_from_usd(s["weth"], to_wei(100, "ether"))

Recommended Mitigation

Set TIMEOUT to the feed heartbeat (e.g. 1 hour for ETH/USD and BTC/USD, or a per-feed timeout), and assert price > 0 in the stale check so an invalid feed price reverts early with a clear error instead of silently zeroing collateral or dividing by zero.

- TIMEOUT: constant(uint256) = 72 * 3600
+ TIMEOUT: constant(uint256) = 1 * 3600 # match the Chainlink feed heartbeat
...
+ assert price > 0, "DSCEngine_InvalidPrice"
assert updated_at != 0, "DSCEngine_StalePrice"
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 24 minutes 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!