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

Stale Price Timeout Far Exceeds ZKsync Chainlink Heartbeat — DSC Minted Against Outdated Collateral Prices

h3xu

Stale Price Timeout Far Exceeds ZKsync Chainlink Heartbeat — DSC Minted Against Outdated Collateral Prices

Scope

  • src/oracle_lib.vy

  • src/oracle_lib.vy

Description

The _stale_check_latest_round_data() function in oracle_lib.vy is expected to reject Chainlink price data that is older than the feed's heartbeat interval. This is a critical safety mechanism to ensure the protocol does not operate on stale prices during periods of oracle inactivity.

The TIMEOUT constant is set to 72 * 3600 (72 hours), but the ZKsync Era Chainlink ETH/USD and BTC/USD feeds have a heartbeat of 1 hour. This means the staleness check will accept price data that is up to 71 hours old, allowing the protocol to accept severely outdated collateral valuations. During an oracle failure window of 1–72 hours, users can deposit WETH/WBTC and mint DSC at prices that no longer reflect market reality, creating undercollateralized positions that cannot be liquidated until the oracle recovers.

# oracle_lib.vy
@> TIMEOUT: constant(uint256) = 72 * 3600 # 72 hours — 71 hours beyond ZKsync Chainlink 1h heartbeat
​
@internal
def _stale_check_latest_round_data(price_feed: AggregatorV3Interface) -> (uint80, int256, uint256, uint256, uint80):
(round_id, price, started_at, updated_at, answered_in_round) = staticcall price_feed.latestRoundData()
assert updated_at != 0, "DSCEngine_StalePrice"
assert answered_in_round >= round_id, "DSCEngine_StalePrice"
@> seconds_since: uint256 = block.timestamp - updated_at
@> assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"
# A price 2 hours stale passes this check despite Chainlink's 1h heartbeat

Risk

Likelihood: Medium

  • Chainlink oracle updates are delayed by ZKsync network congestion, high gas prices, or infrastructure outages — a known occurrence on newer L2 networks.

  • The 71-hour acceptance window makes oracle staleness invisible to the protocol during the most dangerous market conditions.

Impact: High

  • Attackers mint DSC against stale (overvalued) collateral prices during an oracle outage, creating positions that are undercollateralized from inception.

  • Legitimate undercollateralized positions cannot be liquidated during the stale window (oracle staleness freezes liquidation too), allowing bad debt to accumulate.

Severity: High

Proof of Concept

An attacker monitors the ZKsync Era Chainlink heartbeat. When the ETH/USD oracle stops updating (e.g., due to network issues), the attacker waits until the actual market price has dropped significantly (say ETH falls from $4000 to $3000), then deposits WETH and mints DSC at the stale $4000 price — receiving 33% more DSC than they should. When the oracle recovers, their position is immediately undercollateralized and may be unliquidatable.

import boa
from eth_utils import to_wei
​
eth_usd.updateAnswer(4000 * 10**8)
boa.env.time_travel(seconds=3602)
​
# Staleness window: 3602s > 3600s (real heartbeat) but < 259200s (72h TIMEOUT)
# Protocol still accepts the 1-hour-old $4000 price
# Real market has moved to $3000 — protocol does not detect this
with boa.env.prank(attacker):
weth.approve(dsce, to_wei(1, "ether"))
dsce.deposit_collateral(weth, to_wei(1, "ether"))
dsce.mint_dsc(to_wei(1000, "ether")) # Succeeds — minted DSC at stale $4000 price

Recommended Mitigation

The TIMEOUT should match the ZKsync Era Chainlink heartbeat for ETH/USD and BTC/USD feeds (1 hour = 3600 seconds). This ensures any price update missed by the oracle is immediately detected and the protocol halts safely.

- TIMEOUT: constant(uint256) = 72 * 3600
+ TIMEOUT: constant(uint256) = 3600 # 1 hour — matches ZKsync Era Chainlink ETH/USD and BTC/USD heartbeat
Updates

Lead Judging Commences

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