M-1 — 72 hour staleness timeout too long
Root + Impact
The time out constraint in the SRC slash oracle underscore lib dot v y file, uh, it it is... it has the It accepts the price that can be old up to seventy two hours, but changelinks price feed updates every hour, so it doesn't make any sense.
Now for the impact, the impact would be high, of course, because someone can deposit an each that the contract thinks, which is two thousand dollars worth, but it is, you know, maybe, like, four... fourteen hundred dollars or fifteen hundred dollars. and, uh, then they can borrow new jump, uh, new jump out, and then just go on away.
Description
The protocol accepts Chainlink price data that is up to 72 hours old, but Chainlink's ETH/USD and BTC/USD price feeds update every 1 hour — meaning the protocol could be operating on prices that are 3 days old during a market crisis, allowing users to mint DSC against collateral that is already worth far less than the system thinks.
Risk
Likelihood:
Low
Impact:
High
Proof of Concept
Chainlink price feed experiences heavy network traffic or an outage
Last valid price update was 48 hours ago — ETH was $2000 at that time
Real market price of ETH has since dropped to $1500
Protocol checks
seconds_since <= TIMEOUT— 48 hours < 72 hours — passesProtocol still believes ETH = $2000
Attacker deposits 2 ETH — protocol values it at $4000 (real value is $3000)
Attacker mints $3500 worth of DSC against the inflated collateral value
Attacker walks away with $3500 DSC backed by collateral actually worth $3000
Protocol is now undercollateralized and cannot recover that difference
Recommended Mitigation
Change TIMEOUT from 72 hours to 2 hours to match Chainlink's 1 hour heartbeat for ETH/USD and BTC/USD feeds on ZKsync Era. This ensures the protocol never operates on prices older than two heartbeat cycles.
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.