# A vault can be locked from MarketplaceZap and StakingZap

Anyone holding a vault vToken can send a tiny amount to the MarketplaceZap/StakingZap contracts, breaking the balance check and locking all mint operations for every user.

- Payout: Audit contest
- Severity: high
- Program: NFTX
- Found by: p4st13r4
- Disclosed: 2022-03-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-12-nftx-findings/issues/107
- Library page: https://bugbountylibrary.com/r/c4%3A2021-12-nftx%3AH-03
- Tags: area:web3 domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** NFTXMarketplaceZap.sol / NFTXStakingZap.sol vault minting flow
**Root cause:** Zap contracts assert their vToken balance equals the freshly minted amount (`require(balance == IERC20Upgradeable(vault).balanceOf(address(this)))`), so any pre-existing balance makes the equality fail.
**Steps:**
1. Obtain any amount > 0 of a vault's vToken.
2. Transfer the vToken directly to NFTXMarketplaceZap (or NFTXStakingZap) address.
3. Any subsequent mint operation through the zap computes balance != contract balanceOf and reverts with 'Did not receive expected balance'.
4. Repeat for each vault to keep marketplace/staking minting permanently unavailable.
**How found:** Code review of the zap mint path noticed the strict equality balance assertion against the contract's own token balance, which is manipulable by any external transfer.
**Exploitation:** Attacker with a vToken balance sends a dust transfer to the zap contract; the strict equality check then fails for all users' mint calls, denying marketplace and staking functionality and locking user funds in pending operations.
**Insight:** Strict equality checks on a contract's own token balance are griefable: any third party can donate dust to break them. Look for `balanceOf(address(this)) == expected` patterns in zap/router contracts and prefer delta accounting.