# redeem() in beforeRedeem is using the wrong owner parameter

TalosStrategyStaked.redeem passes receiver instead of _owner to flywheel.accrue, so burned owner's shares skip reward accrual and they lose rewards.

- Payout: Contest reward
- Severity: high
- Program: Maia DAO Ecosystem
- Credited: bin2chen
- Disclosed: 2023-09-18
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-05-maia-findings/issues/730
- Library page: https://bugbountylibrary.com/r/c4%3A2023-05-maia%3AH-07
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** TalosStrategyStaked ERC4626 redeem / flywheel reward accounting
**Root cause:** beforeRedeem(_tokenId, receiver) is called with the receiver address, but _burn(_owner, shares) burns the owner's shares; flywheel.accrue updates the wrong userIndex, so the owner's rewards are not settled before their shares decrease.
**Steps:**
1. Call redeem(shares, amount0Min, amount1Min, receiver, _owner) where receiver != _owner.
2. Observe beforeRedeem(_tokenId, receiver) accrues flywheel for receiver, not _owner.
3. Shares are burned from _owner without accruing _owner's rewards.
4. Owner's unaccrued rewards are lost/misattributed.
**How found:** Code reading of redeem(): noticed beforeRedeem receives receiver while _burn uses _owner, a parameter mismatch in reward-accrual ordering.
**Exploitation:** Any redeem where receiver differs from _owner (e.g. redeem on behalf of another via allowance) skips accrual for the actual share owner, causing reward loss to that owner.
**Insight:** In reward-accruing vaults, verify the address passed to accrue() matches the address whose balance is mutated (burn/mint/transfer), especially when receiver and owner are distinct parameters.