Oracle staleness uses one fixed 72h TIMEOUT for all feeds, not each feed's heartbeat — stale prices accepted for 3 days
Description
oracle_lib uses a single fixed 72-hour staleness window for all feeds, instead of each Chainlink feed's own heartbeat:
The library's own docstring says it should "use the Chainlink feed heartbeat to determine if a feed is stale". Major feeds (ETH/USD, BTC/USD) have heartbeats around 3600s; a price that has not updated for up to 3 days is clearly stale yet still accepted. For up to 72h the engine values collateral at a price that may be wildly out of date.
Risk
Likelihood: Medium
During volatility a feed that stops updating within its normal ~1h heartbeat stays "fresh" for up to 3 days under this check — a realistic operational condition.
Impact: Medium
The protocol acts on stale prices for up to 72 hours: under-collateralized positions are not liquidatable (bad debt), or users mint/redeem against an outdated valuation. The anti-stale protection is neutered to a 3-day window.
Proof of Concept
Recommended Mitigation
Store and use a per-feed heartbeat (plus a small buffer) rather than one global 72h constant:
Lead Judging Commences
[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) ```
Rewards breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Judging
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsRewards Distribution
The contest is complete and the rewards are being distributed.