# Deposits from L1 to L2 using L1CrossDomainMessenger will fail and will not be replayable when L2CrossDomainMessenger is paused

Pausing L2CrossDomainMessenger makes L1→L2 deposits revert in relayMessage while sendMessage still succeeds, minting value to the aliased messenger address with no replay path.

- Payout: Contest reward
- Severity: medium
- Program: Optimism
- Credited: rvierdiiev
- Disclosed: 2023-01-19
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-01-optimism-judging/issues/57
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-01-optimism%3AM-12
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm technique:source-review vuln:business-logic vuln:dos

**Target:** L1CrossDomainMessenger / L2CrossDomainMessenger bridge contracts
**Root cause:** sendMessage lacks whenNotPaused while relayMessage has it, so deposits can be initiated during a pause but never relayed; the failed relay leaves minted value at the aliased L2CrossDomainMessenger address with no stored replay data.
**Steps:**
1. Pause L2CrossDomainMessenger (relayMessage reverts via whenNotPaused).
2. User calls L1CrossDomainMessenger.sendMessage with ETH; succeeds since sendMessage is not pause-gated.
3. OptimismPortal emits TransactionDeposited; off-chain service relays tx to L2.
4. Value is minted to aliased L2CrossDomainMessenger address; relayMessage reverts.
5. Deposit is unreplayable; funds stuck/lost.
**How found:** Code reading of CrossDomainMessenger pause modifiers: noticed sendMessage lacks whenNotPaused while relayMessage has it, then reasoned about the L1→L2 deposit flow during an L2-side pause, contrasting with the known-issue note about L1 pause withdrawals.
**Insight:** When a contract has asymmetric pause gating between initiation and settlement functions, check the cross-chain counterpart's pause state: a paused destination messenger can strand in-flight messages that the source still accepts.