# GiantLP with a transferHookProcessor cant be burned, users' funds will be stuck in the Giant Pool

GiantLP burn passes address(0) to transfer hook, hitting a zero-address require in reward distribution and reverting all withdrawals, locking user funds.

- Payout: Contest reward
- Severity: high
- Program: Stakehouse Protocol
- Credited: ronnyx2017
- Disclosed: 2023-01-20
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-11-stakehouse-findings/issues/116
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-stakehouse%3AH-07
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:dos

**Target:** GiantLP / GiantMevAndFeesPool withdrawETH
**Root cause:** ERC20 _burn calls beforeTokenTransfer with _to = address(0); the hook routes to _distributeETHRewardsToUserForToken which requires recipient != address(0), so burn reverts.
**Steps:**
1. Deploy GiantMevAndFeesPool with a transferHookProcessor (GiantLP hook enabled).
2. As user, call `giantFeesAndMevPool.depositETH{value: 4 ether}(4 ether)`.
3. Call `giantFeesAndMevPool.withdrawETH(4 ether)`.
4. Observe GiantLP::burn -> beforeTokenTransfer(from, 0x0, amount) -> _distributeETHRewardsToUserForToken(0x0) reverts with 'Zero address'.
**How found:** Code reading of GiantLP transfer hook wiring: noticed _burn passes address(0) as `to`, then traced GiantMevAndFeesPool.beforeTokenTransfer into SyndicateRewardsProcessor._distributeETHRewardsToUserForToken and spotted the zero-address require; confirmed with a Foundry PoC.
**Exploitation:** Any user attempting to withdraw ETH from the Giant Pool triggers a burn of their GiantLP; the transfer hook distributes rewards to the zero address and reverts, so withdrawal is impossible and funds remain stuck in the pool.
**Insight:** When an ERC20 uses transfer hooks, audit the burn/mint paths: _burn passes address(0) as recipient, so any hook logic that validates or distributes to `to` will revert and brick withdrawals.