Every price the engine reads passes through oracle_lib._stale_check_latest_round_data (dsc_engine.vy:313 and :359). The library's NatSpec defines the intended behaviour: the engine should freeze when prices become stale, and staleness should be judged by the Chainlink feed heartbeat.
The check uses one constant, TIMEOUT = 72 * 3600, for every feed (oracle_lib.vy:15, :47-48). The heartbeat is never used. If the ZKsync ETH/USD and BTC/USD heartbeat is about 24h, a feed that stops updating is still accepted for about 48h after the point at which the spec treats it as stale. That heartbeat figure is an external assumption the repo cannot confirm; the PoC's engine assertions hold for any heartbeat under 48h. Throughout that window, minting, health checks, redemption and liquidation all use the frozen price. The engine does freeze, but late: only at 72h + 1s.
Likelihood:
This occurs when a Chainlink feed stops updating for longer than its heartbeat (an oracle or network incident) while the market moves. While the feed is working, deviation-triggered updates keep the price current.
No attacker can cause the outage. Once it happens, anyone can mint or liquidate inside the window.
Impact:
Over-minting and missed liquidations. ETH/USD is frozen at $2,000 for 48h while the market is at $1,500. A user mints 1,000 DSC on 1 WETH: the engine sees HF 1.0, but real collateral is 150% against the required 200% (real HF 0.75). The same mint reverts at a fresh $1,500. A victim at real HF 0.8333 reads as 1.1111, so liquidate reverts DSCEngine__HealthFactorOk. If the real price falls below 50% of the stale price within the window (shown at $900), the minted DSC is unbacked: $100 per WETH in the PoC.
Wrongful liquidations. ETH/USD is frozen low at $1,700 for 48h while the market is at $2,200. A victim who is healthy at market (HF 1.2222, liquidation reverts at a fresh $2,200) is liquidated for 450 DSC and loses 0.291176 WETH, which is $640.59 at market: a 42.4% premium instead of the 10% bonus. That victim was already liquidatable when $1,700 was fresh. The added harm is that the liquidation lands inside the window a heartbeat-based check would have frozen.
The PoC deploys the real dsc_engine.vy, decentralized_stable_coin.vy and oracle_lib.vy with the repo mocks; only WETH is deposited. Feed age is produced with boa.env.time_travel and no feed update. As a contrast, it compiles an in-memory copy of oracle_lib.vy with TIMEOUT = 25 * 3600 (24h heartbeat + 1h buffer). On the same 48h-old feed, the original accepts the price and the copy reverts DSCEngine_StalePrice.
Run from the repo root: .venv/Scripts/python poc/poc_AS-04.py
The script ends with: PASS: AS-04 - engine runs on prices 48h old (past the assumed 24h heartbeat) and freezes only at 72h+1s
Pass a per-feed maximum age (the feed's heartbeat plus a small buffer), set at construction, instead of one global constant.
## 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) ```
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.