# OCL_ZVE::pushToLockerMulti() will revert due to incorrect assert() statements when interacting with UniswapV2

OCL_ZVE.pushToLockerMulti asserts router allowance is zero after addLiquidity, but 90% min amounts leave residual allowance, reverting liquidity provision.

- Payout: Contest reward
- Severity: medium
- Program: Zivoe
- Credited: 0rpse
- Disclosed: 2024-03-19
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-03-zivoe-judging/issues/18
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-03-zivoe%3AM-2
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** OCL_ZVE locker contract / UniswapV2 router
**Root cause:** pushToLockerMulti approves full balances but passes 90% minimums to addLiquidity; the router consumes less than the full allowance, so the post-call assert(allowance==0) fails.
**Steps:**
1. Call OCL_ZVE.pushToLockerMulti() with pairAsset and ZVE balances.
2. Contract safeIncreaseAllowance(router, balPairAsset) and balZVE.
3. Calls router.addLiquidity(pairAsset, ZVE, balPairAsset, balZVE, balPairAsset*9/10, balZVE*9/10, ...).
4. Router deposits amountA/amountB between min and desired, leaving residual allowance.
5. assert(IERC20(pairAsset).allowance(this,router)==0) reverts.
**How found:** Read UniswapV2Router02._addLiquidity to see deposited amounts fall between amountMin and amountDesired, then compared to the contract's strict allowance==0 asserts.
**Insight:** When a contract approves full balances but passes slippage-minimums to a router, the router consumes less than approved; never assert allowance==0 after such calls—decrease by the returned deposited amounts instead.