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

oracle_lib hardcodes a 72 hour staleness window for every feed, so the engine prices on data up to 3 days old

nexus0ps

Description

oracle_lib is the single staleness guard for every price read. Its own NatSpec states the intent (src/oracle_lib.vy:8-9):

We should use the Chainlink feed heartbeat to determine if a feed is stale or not.

The implementation instead applies one hardcoded constant to every feed (src/oracle_lib.vy:15):

TIMEOUT: constant(uint256) = 72 * 3600

and the only freshness check is (src/oracle_lib.vy:47-48):

seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= TIMEOUT, "DSCEngine_StalePrice"

Chainlink USD feeds for major assets such as ETH update on a heartbeat on the order of one hour, far shorter than three days. A 72 hour window means any answer younger than 72 hours is treated as fresh, so a price up to three days old is accepted. Every function that prices collateral, namely mint_dsc, redeem_collateral, health_factor and liquidate, then acts on whatever the last answer was even if it is far out of date. A user can mint against a stale high price, or avoid a liquidation that the current price would justify. The gap between the stated heartbeat intent and the single hardcoded constant is the defect.

Risk

Likelihood: Medium. Chainlink feeds do go hours without an update during incidents or quiet deviation windows, and a 72 hour tolerance makes accepting hours-old data realistic in normal operation.

Impact: Medium. Minting and liquidation can run on a stale price, letting a position be opened that is not collateralized at the current price or escape a liquidation it should be subject to, which weakens the backing of the peg. The proof shows that a price 71 hours old is accepted as fresh and that the guard only reverts once the age passes 72 hours.

Proof of Concept

Self contained moccasin/titanoboa test using time travel. Save as tests/poc_oracle_staleness.py and run uv run mox test tests/poc_oracle_staleness.py -s.

import boa
​
from src import dsc_engine, decentralized_stable_coin
from src.mocks import MockV3Aggregator
​
PLAIN_ERC20_SRC = """
# pragma version ^0.4.0
balanceOf: public(HashMap[address, uint256])
allowance: public(HashMap[address, HashMap[address, uint256]])
totalSupply: public(uint256)
decimals: public(uint8)
@deploy
def __init__():
self.decimals = 18
@external
def mint(to: address, amount: uint256):
self.balanceOf[to] += amount
self.totalSupply += amount
@external
def approve(spender: address, amount: uint256) -> bool:
self.allowance[msg.sender][spender] = amount
return True
@external
def transfer(to: address, amount: uint256) -> bool:
self.balanceOf[msg.sender] -= amount
self.balanceOf[to] += amount
return True
@external
def transferFrom(owner: address, to: address, amount: uint256) -> bool:
self.allowance[owner][msg.sender] -= amount
self.balanceOf[owner] -= amount
self.balanceOf[to] += amount
return True
"""
​
HOUR = 3600
​
​
def test_oracle_accepts_71h_stale_price():
weth = boa.loads(PLAIN_ERC20_SRC)
wbtc = boa.loads(PLAIN_ERC20_SRC)
eth_usd = MockV3Aggregator.deploy(8, 2_000 * 10**8)
btc_usd = MockV3Aggregator.deploy(8, 30_000 * 10**8)
​
dsc = decentralized_stable_coin.deploy()
engine = dsc_engine.deploy(
[weth.address, wbtc.address], [eth_usd.address, btc_usd.address], dsc.address
)
dsc.set_minter(engine.address, True)
dsc.transfer_ownership(engine.address)
​
# eth_usd price was stamped "now". Let it age 71 hours without any update.
boa.env.time_travel(seconds=71 * HOUR)
​
# The engine still accepts the 71-hour-old price as fresh (no revert).
value = engine.get_usd_value(weth.address, 1 * 10**18)
assert value == 2_000 * 10**18
print(f"71h-old price accepted as fresh: 1 WETH valued at ${value/10**18:,.0f}")
​
# Only past the 72h hardcoded TIMEOUT does the staleness guard finally trip.
boa.env.time_travel(seconds=2 * HOUR) # now ~73h old
with boa.reverts("DSCEngine_StalePrice"):
engine.get_usd_value(weth.address, 1 * 10**18)
print("Staleness only trips after 72h (vs ~1h real heartbeat)")

Output (test passes):

71h-old price accepted as fresh: 1 WETH valued at $2,000
Staleness only trips after 72h (vs ~1h real heartbeat)
1 passed

Recommended Mitigation

Apply a per-feed timeout sized to each feed's real heartbeat rather than one global 72 hour constant. Store the timeout alongside each feed and check against it:

# in the engine, set when registering each feed:
feed_to_timeout: public(HashMap[address, uint256]) # e.g. 3600 for a 1h heartbeat feed
​
# in oracle_lib, take the timeout from the caller instead of a constant:
@internal
@view
def _stale_check_latest_round_data(
price_price_address: address, max_staleness: uint256
) -> (uint80, int256, uint256, uint256, uint80):
...
seconds_since: uint256 = block.timestamp - updated_at
assert seconds_since <= max_staleness, "DSCEngine_StalePrice"
...

If a single constant must be kept, set it to the tightest supported heartbeat, which for ETH/USD and BTC/USD is roughly 3600, instead of 72 * 3600.

Updates

Lead Judging Commences

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