Algo Ssstablecoinsss

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

TIMEOUT is a hardcoded constant of 72 hours with no mechanism for adjustment, making oracle staleness detection inflexible across different assets and market conditions

Root + Impact

TIMEOUT = 72 * 3600 is baked in at compile time. The same 72-hour window applies to every price feed regardless of asset volatility, oracle update frequency, or changing protocol requirements. There is no owner function to update the value post-deployment, so any mismatch between the hardcoded window and real-world oracle behaviour requires a full contract redeployment.

Description

  • oracle_lib.vy uses TIMEOUT to determine whether a Chainlink price is stale:

# src/oracle_lib.vy
TIMEOUT: constant(uint256) = 72 * 3600 # @> hardcoded 72 hours, no setter
@internal
def _get_chainlink_data_last_updated(
price_feed: AggregatorV3Interface
) -> (uint256, uint256):
round_id: uint80 = 0
answer: int256 = 0
started_at: uint256 = 0
updated_at: uint256 = 0
answered_in_round: uint80 = 0
(round_id, answer, started_at, updated_at, answered_in_round) = price_feed.latestRoundData()
assert block.timestamp - updated_at <= TIMEOUT, "Price is stale" # @> fixed window
return (convert(answer, uint256), updated_at)
  • Different Chainlink feeds have different heartbeat intervals: ETH/USD updates every hour in volatile conditions; BTC/USD updates every 24 hours. A 72-hour window is too permissive for high-frequency feeds (accepts stale data) and may be too tight for feeds with longer heartbeats if the network congestion delays updates.

  • Because TIMEOUT is a constant, it cannot be adjusted without redeploying the contract, breaking all existing user positions.

Risk

Likelihood:

  • The fixed timeout will drift out of alignment with oracle update schedules as the protocol scales to additional assets or as Chainlink updates its heartbeat configurations.

Impact:

  • If TIMEOUT is too long, the protocol accepts stale prices during oracle downtime or manipulation windows — enabling under-collateralised borrowing or unfair liquidations. If a future feed has a shorter heartbeat, the 72-hour window accepts prices that are hours old.

Proof of Concept

The test confirms that a price updated 71 hours ago is accepted as fresh, even though many Chainlink feeds update far more frequently (hourly heartbeat). A protocol with an hourly-heartbeat feed should reject data older than ~1–2 hours, not 72.

def test_stale_price_accepted_within_72h(oracle_lib, mock_feed, price):
# Simulate price last updated 71 hours ago
mock_feed.set_updated_at(chain.time() - 71 * 3600)
# Oracle returns the stale price without reverting
returned_price, _ = oracle_lib._get_chainlink_data_last_updated(mock_feed)
assert returned_price == price # 71-hour-old price accepted as valid

A feed with a 1-hour heartbeat should flag this as stale — the fixed 72-hour constant provides no protection.

Recommended Mitigation

Replace the compile-time constant with a per-feed configurable timeout stored in a mapping, with an owner-restricted setter:

- TIMEOUT: constant(uint256) = 72 * 3600
+ feed_timeout: HashMap[address, uint256]
+ DEFAULT_TIMEOUT: constant(uint256) = 72 * 3600
+ @external
+ def set_feed_timeout(feed: address, timeout: uint256):
+ assert msg.sender == self.owner, "Only owner"
+ assert timeout > 0 and timeout <= 7 * 24 * 3600, "Timeout out of range"
+ self.feed_timeout[feed] = timeout
assert block.timestamp - updated_at <= self.feed_timeout[price_feed.address], "Price is stale"

This allows the protocol to tune staleness windows per asset without redeployment.

Updates

Lead Judging Commences

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