# L2SharedBridge l1LegacyBridge is not set

L2SharedBridge.initialize never assigns l1LegacyBridge, leaving it address(0), so legacy L1ERC20Bridge deposits fail finalizeDeposit until users reclaim via claimFailedDeposit.

- Payout: Contest reward
- Severity: medium
- Program: zkSync
- Credited: bin2chen
- Disclosed: 2024-05-29
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-03-zksync-findings/issues/77
- Library page: https://bugbountylibrary.com/r/c4%3A2024-03-zksync%3AM-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** L2SharedBridge.initialize / finalizeDeposit on Era chain
**Root cause:** initialize() only requires _l1LegecyBridge != address(0) but never assigns it to the l1LegacyBridge storage variable, so it stays address(0).
**Steps:**
1. Deploy/upgrade L2ERC20Bridge to L2SharedBridge on ERA_CHAIN_ID via initialize(_l1Bridge, _l1LegecyBridge, hash, owner).
2. Observe l1LegacyBridge remains address(0) after init.
3. Send a deposit through the old L1ERC20Bridge before it is upgraded.
4. finalizeDeposit on L2 rejects the message because l1LegacyBridge check fails; deposit cannot complete.
5. User must call claimFailedDeposit on L1 to recover funds.
**How found:** Read the documented migration order (L2 upgraded before L1) and code-reviewed initialize(), noticing the require on _l1LegecyBridge with no corresponding assignment.
**Insight:** When a migration doc mandates backward compatibility with a legacy contract, verify the legacy address is actually persisted in storage during reinitialization, not just validated as non-zero.