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

TIMEOUT is a hardcoded constant of 72 hours, making the oracle staleness window inflexible and unable to adapt to market price update frequency

0xj3d1

Root + Impact

Description

  • oracle_lib treats a price as stale only after a fixed TIMEOUT of 72 hours (259200 seconds), used in the single staleness assertion.

  • This constant is hardcoded and cannot be adjusted per feed or per market conditions, so it cannot adapt to the actual heartbeat/update frequency of the price feeds the protocol relies on.

// Root cause in the codebase with @> marks to highlight the relevant section

Risk

Likelihood:

  • The TIMEOUT applies to every price read on every mint, redeem, and liquidation, so the fixed window governs all oracle-dependent operations at all times.

  • It is a compile-time constant with no setter, so it cannot track changing market conditions or differing feed heartbeats.

Impact:

  • 72 hours is far longer than a typical ETH/BTC feed heartbeat, so the protocol can accept and act on prices that are up to three days stale, mispricing mints and liquidations during volatile periods.

  • Because the window cannot be tuned per feed or per market, it is simultaneously too loose for fast-moving assets and impossible to tighten without a redeploy, leaving the staleness check misaligned with real update frequency.

Proof of Concept

The test records a fresh price, advances 71 hours (well beyond any ETH/BTC heartbeat but under the 72h TIMEOUT), and shows the oracle still returns the stale price without reverting:

def test_poc_fixed_timeout_accepts_stale(feed, oracle):
t0 = boa.env.evm.patch.timestamp
feed.updateRoundData(1, 2000 * 10**8, t0, t0)
​
# Advance 71 hours — absurdly stale for ETH/USD, but under the 72h TIMEOUT.
boa.env.time_travel(seconds=71 * 3600)
​
round_id, price, started_at, updated_at, answered = (
oracle.stale_check_latest_round_data(feed.address)
)
assert price == 2000 * 10**8 # stale price accepted
assert (boa.env.evm.patch.timestamp - updated_at) > 24 * 3600 # >24h stale

Run: mox test --match test_poc_fixed_timeout_accepts_stale -vvv

Observed: a price 71 hours old is returned without reverting; only past the fixed 72h does it revert. The hardcoded constant cannot be tuned to a feed's real heartbeat.

Recommended Mitigation

Replace the single hardcoded TIMEOUT with a configurable, per-feed staleness window sized to each feed's heartbeat (e.g. ~1 hour for ETH/BTC), set at deployment and adjustable by governance:

- TIMEOUT: constant(uint256) = 72 * 3600
+ # per-feed heartbeat, configurable rather than a single hardcoded constant
+ timeout: public(uint256) # set in __init__ / adjustable, sized to the feed heartbeat
Updates

Lead Judging Commences

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