# Bypass zap timelock

NFTXStakingZap's 7-day inventory lock is overwritten to 2ms by calling NFTXInventoryStaking.deposit, letting users bypass the zap timelock.

- Payout: Audit contest
- Severity: medium
- Program: NFTX
- Found by: gzeon
- Disclosed: 2022-03-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-12-nftx-findings/issues/178
- Library page: https://bugbountylibrary.com/r/c4%3A2021-12-nftx%3AM-09
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:business-logic

**Target:** NFTXStakingZap / NFTXInventoryStaking / XTokenUpgradeable timelock logic
**Root cause:** _timelockMint sets timelock[account] = block.timestamp + timelockLength unconditionally, overwriting a longer existing timelock with a shorter one instead of taking the max.
**Steps:**
1. Observe NFTXStakingZap.inventoryLockTime defaults to 7 days, while NFTXInventoryStaking.DEFAULT_LOCKTIME is 2 ms.
2. Call NFTXInventoryStaking.deposit, which invokes _timelockMint with the 2 ms locktime.
3. timelock[account] is overwritten to block.timestamp + 2 ms, replacing the prior 7-day lock.
4. Withdraw/unlock immediately, bypassing the intended zap timelock.
**How found:** Compared the default timelock constants across NFTXStakingZap (7 days) and NFTXInventoryStaking (2 ms), then read _timelockMint and noticed it overwrites rather than maxes the existing timelock.
**Exploitation:** A user who would otherwise be locked 7 days via the zap calls deposit on NFTXInventoryStaking to reset their timelock to 2 ms, then exits immediately.
**Insight:** When two contracts share a timelock mapping with different default durations, check whether the setter takes max(existing, new) or blindly overwrites — a shorter-path call can reset a longer lock.