# Incorrect calculation of required gas limit during deposit transaction

OptimismPortal's _gasLimit lower bound ignores calldata intrinsic gas, letting depositors pick a gas limit that skips L1 gas burn while still passing checks.

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

**Target:** OptimismPortal depositTransaction / ResourceMetering gas burn
**Root cause:** The _gasLimit lower bound is a flat 21000, not accounting for calldata intrinsic gas, so a _gasLimit between 21000 and the burn-triggering threshold passes the require but fails to burn L1 gas in ResourceMetering.
**Steps:**
1. Call `depositTransaction` with a long `_data` payload to inflate `usedGas`.
2. Choose `_gasLimit` such that `21000 <= _gasLimit <= usedGas * max(block.basefee, 1 gwei) / prevBaseFee`.
3. Observe the `require(_gasLimit >= 21000)` passes but ResourceMetering's burn condition is not triggered, so no L1 gas is burned.
**How found:** Code review of the _gasLimit require in OptimismPortal against the burn condition in ResourceMetering, noticing the lower bound omits calldata intrinsic gas.
**Exploitation:** Depositor submits a deposit with large calldata and a _gasLimit in the bypass window, paying only L1 tx gas while the sequencer processes L2 work uncompensated; repeated use drains sequencer resources.
**Insight:** When a contract enforces a minimum gas limit to gate a resource-metering burn, check whether the minimum covers intrinsic calldata gas; large calldata can widen the window between the floor and the burn threshold.