# LaunchToken transfers cause staking rewards to be lost to the LaunchPad

Distributor pays pending staking rewards to msg.sender (LaunchPad) instead of the recipient during LaunchToken transfers, losing user earnings.

- Payout: Contest reward
- Severity: medium
- Program: GTE
- Credited: hgrano
- Disclosed: 2026-02-05
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-08-gte-perps-and-launchpad#m-17
- Library page: https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-17
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** launchpad/Distributor.sol staking reward distribution
**Root cause:** In the _beforeTokenTransfer -> increaseStake path, Distributor distributes pending earnings to msg.sender (the LaunchPad) rather than the actual account being credited.
**Steps:**
1. Call `LaunchToken::transferFrom` while token is locked.
2. `_beforeTokenTransfer` hook calls `increaseStake` on LaunchPad for the `to` account.
3. LaunchPad calls `increaseStake` on Distributor.
4. Distributor distributes pending earnings on lines 170/175 to `msg.sender` (LaunchPad) instead of `to`.
5. Recipient loses all pending staking earnings.
**How found:** Code reading of the transfer hook chain (_beforeTokenTransfer -> LaunchPad.increaseStake -> Distributor.increaseStake) revealed msg.sender used as payout recipient instead of the credited account.
**Exploitation:** Any user sending LaunchTokens to another user triggers the hook; the recipient's pending earnings are paid to the LaunchPad contract, causing partial or complete loss of staking rewards.
**Insight:** When a hook chain crosses contracts, msg.sender at the inner call is the intermediate contract, not the original user; audit reward-payout recipient variables across such call chains.