# Incorrect checking in _assertUserHasEnoughGiantLPToClaimVaultLP

GiantPoolBase checks the wrong token's lastInteractedTimestamp, so batch withdrawDETH/withdrawLPTokens calls fail after the first LP token, breaking batch operations.

- Payout: Contest reward
- Severity: medium
- Program: Stakehouse Protocol
- Credited: hihen
- Disclosed: 2023-01-20
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-11-stakehouse-findings/issues/382
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-stakehouse%3AM-25
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic

**Target:** GiantPoolBase / GiantSavETHVaultPool Solidity contracts
**Root cause:** _assertUserHasEnoughGiantLPToClaimVaultLP checks lpTokenETH.lastInteractedTimestamp instead of the specific _token being withdrawn; burning lpTokenETH updates that timestamp, so subsequent batch items in the same tx fail the 'Too new' require.
**Steps:**
1. Call withdrawDETH() or withdrawLPTokens() with more than one lpToken in the batch.
2. First iteration passes the require and calls lpTokenETH.burn(msg.sender, amount), updating lastInteractedTimestamp[msg.sender] to block.timestamp.
3. Second iteration hits `require(lpTokenETH.lastInteractedTimestamp(msg.sender) + 1 days < block.timestamp, "Too new")` and reverts.
4. Batch call fails entirely; user can only withdraw one LPToken per day.
**How found:** Code reading of the withdraw flow: noticed the require reads lpTokenETH's timestamp while the burn in the same function updates that same timestamp, making multi-token batches self-defeating.
**Insight:** When a guard reads a timestamp/state that the function itself mutates mid-loop, check whether batch iterations invalidate their own precondition; the guard should key on the per-item token, not a shared token.