# No check for active Arbitrum Sequencer in WSTETH Oracle

WSTETHOracle on Arbitrum omits the Chainlink sequencer uptime check, letting users borrow against stale prices during a sequencer outage.

- Payout: Contest reward
- Severity: medium
- Program: Sentiment
- Credited: obront
- Disclosed: 2022-10-31
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-11-sentiment-judging/issues/3
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-11-sentiment%3AM-4
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:oracle-manipulation

**Target:** WSTETHOracle.sol price oracle on Arbitrum
**Root cause:** WSTETHOracle.getPrice trusts Chainlink data without consulting the L2 Sequencer Uptime Feed, unlike ArbiChainlinkOracle which implements the check.
**Steps:**
1. Observe ArbiChainlinkOracle.sol calls isSequencerActive() before returning price
2. Read WSTETHOracle.sol getPrice (L45-57) and note no sequencer check
3. During a sequencer outage, L1 rollup contract still accepts user interactions while oracle prices are stale
4. User borrows against stale inflated collateral value, exceeding safe LTV
**How found:** Code review comparing oracle implementations: noticed ArbiChainlinkOracle enforces the Chainlink-recommended sequencer uptime check while WSTETHOracle omits it.
**Exploitation:** Attacker waits for Arbitrum sequencer downtime; while prices are stale, interacts directly via L1 optimistic rollup contract to borrow more than the true collateral value supports, leaving bad debt.
**Insight:** When a protocol has multiple oracle adapters, diff them against each other and against Chainlink's L2 guidance; a check present in one adapter but missing in a sibling is a reliable bug signal.