Algo Ssstablecoinsss

AI First Flight #2
Beginner FriendlyDeFi
EXP
View results
Submission Details
Impact: medium
Likelihood: medium
Invalid

Missing ZKsync Era L2 Sequencer Uptime Feed Check & Hardcoded 72-Hour Staleness Timeout

Summary

oracle_lib.vy contains a hardcoded 72-hour staleness threshold and does not integrate the Chainlink L2 Sequencer Uptime Feed on ZKsync Era. If the ZKsync Era sequencer experiences an outage and comes back online, transactions may be processed against stale L1-originated prices before the Chainlink price feed updates. Furthermore, a 72-hour timeout allows price feeds to lag by up to 3 days before transactions revert.

Vulnerability Details

In src/oracle_lib.vy:

# Line 13
TIMEOUT: constant(uint256) = 3 * 3600 * 24 # 72 hours

In _stale_check_latest_round_data():

# Lines 39-41
if updated_at == 0 or block.timestamp - updated_at > TIMEOUT:
raise "OracleLib__StalePrice"

The protocol targets deployment on ZKsync Era. Chainlink documentation explicitly states:

"When an L2 sequencer experiences an outage, transactions queued during the outage are processed in the order received when the sequencer restarts. Price feeds might not be updated immediately upon reboot, causing transactions to execute against stale prices."

To protect against this, protocols deployed on Layer 2 rollups must query the Chainlink L2 Sequencer Uptime Feed and verify that:

  1. The sequencer is active (status == 0).

  2. An appropriate grace period (e.g. 3,600 seconds) has elapsed since the sequencer restarted before accepting price updates.

Additionally, standard heartbeat intervals for Chainlink price feeds on ZKsync Era (and Ethereum) are:

  • ETH/USD: 24-hour heartbeat (or 0.5% deviation threshold).

  • BTC/USD: 24-hour heartbeat (or 0.5% deviation threshold).

A 72-hour timeout allows the contract to accept prices that are up to 3 days old during prolonged network congestion or oracle infrastructure failure, during which underlying asset values may have fluctuated dramatically.

Impact

  • Sequencer Downtime Exploitation: Upon sequencer reboot, MEV searchers and arbitrageurs can frontrun liquidations or borrow stablecoins using stale collateral prices before feeds synchronize.

  • Extreme Price Staleness: Liquidations and minting continue to execute against prices that are days out of date, creating bad debt.

Tools Used

  • Manual Code Review & Chainlink L2 Integration Guidelines

  • Architectural Threat Modeling

Recommended Mitigation

  1. Implement a check against Chainlink's ZKsync Era Sequencer Uptime Feed:

interface ISequencerUptimeFeed:
def latestRoundData() -> (uint80, int256, uint256, uint256, uint80): view
def check_sequencer_status(uptime_feed: address, grace_period: 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) = staticcall ISequencerUptimeFeed(uptime_feed).latestRoundData()
assert answer == 0, "OracleLib__SequencerDown"
assert block.timestamp - started_at > grace_period, "OracleLib__GracePeriodNotOver"
  1. Reduce the TIMEOUT constant to an asset-appropriate heartbeat interval plus a reasonable margin (e.g. 3 hours for volatile feeds or 25 hours for standard 24-hour feeds).

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 2 hours ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!