# Incorrect asset address causes revert in ApproveAndRedeem5115VaultHook

ApproveAndRedeem5115VaultHook stores tokenIn as asset in preExecute, so postExecute balance subtraction underflows and reverts, blocking all redemptions and fee collection.

- Payout: Contest reward
- Severity: medium
- Program: Superform
- Credited: Audittens
- Disclosed: 2025-07-17
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_superform_may2025.pdf#3.2.13
- Library page: https://bugbountylibrary.com/r/cantina%3Asuperform_may2025%3A3.2.13
- Tags: domain:web3 impact:dos kind:contest platform:cantina sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** ApproveAndRedeem5115VaultHook smart contract hook
**Root cause:** _preExecute reads asset from data offset 24 (tokenIn) instead of offset 44 (tokenOut), so _postExecute computes balanceOf(tokenIn) after redeem minus pre-redeem balance, which is negative and underflows.
**Steps:**
1. Call hook flow: preExecute stores asset=toAddress(slice(data,24,20)) and outAmount=balanceOf(asset)
2. build returns approve tokenIn->yieldSource and redeem call, decreasing tokenIn balance
3. postExecute computes _getBalance(account,data) - outAmount on tokenIn, now smaller, causing underflow revert
4. Fix: read asset from slice(data,44,20) (tokenOut)
**How found:** Traced hook lifecycle (preExecute/build/execute/postExecute) and noticed asset offset 24 matches tokenIn in build, making the post-execution balance delta negative.
**Insight:** In hook-based vault flows, verify that the token whose balance delta is measured post-execution is the received tokenOut, not the spent tokenIn; mismatched offsets silently invert the delta sign.