# The collect() function will always TRANSFER ZERO fees, losing _feesPositions without receiving fees!

Timeswap V2 LiquidityToken collect() calls transferFees before computing fee amounts, so users burn fee positions while receiving zero fees.

- Payout: Contest reward
- Severity: high
- Program: Timeswap
- Credited: chaduke
- Disclosed: 2023-03-10
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-01-timeswap-findings/issues/121
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-timeswap%3AH-03
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** TimeswapV2LiquidityToken collect() function
**Root cause:** transferFees is invoked with long0Fees/long1Fees/shortFees before getFees() assigns them, so the values are still zero; the subsequent burn() destroys the fee position anyway.
**Steps:**
1. Call `collect(param)` on TimeswapV2LiquidityToken with a non-zero fee position.
2. Observe `transferFees(...)` executes with long0Fees=long1Fees=shortFees=0.
3. Observe `getFees()` computes real amounts only after the transfer.
4. Observe `_feesPositions[id][msg.sender].burn(long0Fees, long1Fees, shortFees)` burns the position, leaving user with no fees.
**How found:** Code reading of collect() ordering: noticed transferFees uses variables that are only assigned by getFees() on the following line.
**Exploitation:** Any user calling collect() on a position with accrued fees loses those fees: the pool transfers zero tokens while the fee position is burned, permanently destroying the claimable value.
**Insight:** When auditing claim/collect functions, verify ordering between amount computation and external transfer/burn calls; uninitialized locals passed to external calls silently transfer zero while state is mutated.