# Mailbox.requestL2Transaction() checks the deposit limit of msg.sender (L1WethBridge) instead of the real depositor of weth from L1, as a result, after certain time, nobody will be able to deposit weth anymore from L1

Mailbox.requestL2Transaction checks deposit limit of msg.sender (L1WethBridge) instead of the real depositor, so once the bridge's cumulative cap is hit, all WETH deposits from L1 revert.

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

**Target:** Mailbox.requestL2Transaction / L1WethBridge deposit flow
**Root cause:** The per-user deposit cap is indexed by msg.sender inside requestL2Transaction, which is the shared L1WethBridge contract rather than the actual user depositing WETH, so all users share one cumulative cap.
**Steps:**
1. Set deposit limit to 10 ether via allowList.setDepositLimit(address(0), true, 10 ether).
2. User1 deposits 3 ether WETH + 0.1 ether ETH via bridgeProxy.deposit -> L1WethBridge.deposit -> Mailbox.requestL2Transaction; s.totalDepositedAmountPerUser[L1WethBridge] = 3.1 ether.
3. User2 deposits 4 ether WETH + 0.1 ether ETH; total = 7.2 ether.
4. User3 deposits 2.7 ether + 1 wei WETH + 0.1 ether ETH; total would be 10 ether + 1 wei, exceeding the 10 ether cap, so the call reverts even though User3's own deposits are far below the cap.
**How found:** Traced the deposit call chain bridgeProxy.deposit -> L1WethBridge.deposit -> Mailbox.requestL2Transaction and noticed the limit accounting keys on msg.sender, which is the bridge contract, not the end user.
**Exploitation:** Any user can push the shared L1WethBridge counter toward the cap with normal deposits; once cumulative WETH deposits through the bridge reach the cap, every subsequent WETH deposit from L1 reverts, permanently disabling the WETH deposit path until the limit is changed.
**Insight:** When a shared intermediary contract forwards user actions, per-user accounting keyed on msg.sender inside the downstream function collapses into a single shared bucket; trace the call chain to see which address the accounting actually attributes value to.