Algo Ssstablecoinsss

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

Oracle Staleness TIMEOUT = 72 Hours Allows Stale Price Exploitation

Oracle Staleness TIMEOUT = 72 Hours Allows Stale Price Exploitation
Scope: src/oracle_lib.vy · src/dsc_engine.vy

Description
The oracle_lib module protects against stale Chainlink prices by reverting if the time since the last price update exceeds TIMEOUT. This ensures the protocol
only operates on fresh price data. However, TIMEOUT is hardcoded to 72 hours — far more permissive than the actual Chainlink heartbeats for both supported
collateral feeds:

oracle_lib.vy

TIMEOUT: constant(uint256) = 72 * 3600 # 72 hours

ETH/USD Chainlink heartbeat: 1 hour → TIMEOUT is 71× too permissive

BTC/USD Chainlink heartbeat: 24 hours → TIMEOUT is 3× too permissive

This creates a window of up to 71 hours where a completely stale ETH/USD price is accepted as valid, allowing attackers who monitor the real market price to
exploit the divergence between the stale on-chain price and the true off-chain price.

Impact
An attacker can exploit a stale price to mint DSC far beyond what the real collateral value supports, or to liquidate healthy positions that appear
undercollateralized against the outdated price. During high-volatility periods — exactly when oracle staleness is most likely — the protocol is most vulnerable
to extraction.

Proof of Concept
T = 0h ETH/USD = $3,000. Chainlink feed updates normally.
T = 1h Chainlink stops updating (network issue, keeper failure).
On-chain price remains $3,000.

T = 24h Real ETH price has crashed to $1,500.
Protocol still reads $3,000. Staleness check:
seconds_since = 24 * 3600 = 86,400
TIMEOUT = 72 * 3600 = 259,200
86,400 <= 259,200 → passes ✓ (stale price accepted)

Attacker deposits 1 ETH (real value: $1,500).
Protocol values it at $3,000 (stale price).
Attacker mints up to 1,500 DSC against $1,500 real collateral.
Real collateralization ratio: 100% — protocol requires 200% (LIQUIDATION_THRESHOLD=50).
Protocol accepts it because stale price says 200%.

T = 72h Feed resumes, price corrects to $1,500.
Attacker's position is immediately undercollateralized.
Protocol has issued DSC backed by insufficient collateral.

Mitigation
Replace the single hardcoded TIMEOUT with per-feed heartbeat values passed at construction. This aligns the staleness window exactly with Chainlink's
guaranteed update frequency — if the feed has not updated within its normal heartbeat window, the price is stale and must be rejected:

Store heartbeat per price feed at deployment

token_address_to_heartbeat: HashMap[address, uint256]

In _stale_check_latest_round_data, use per-feed heartbeat:

heartbeat: uint256 = self.token_address_to_heartbeat[price_feed]
assert seconds_since_last_update <= heartbeat, "OracleLib__StalePrice"

At construction:

ETH/USD feed → heartbeat = 3600 (1 hour)

BTC/USD feed → heartbeat = 86400 (24 hours)

Using the Chainlink-published heartbeat is safe because Chainlink guarantees an update within that window under normal conditions. Any staleness beyond it
indicates a feed failure and the protocol should halt rather than accept the outdated price.

Updates

Lead Judging Commences

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