# Reward accrual keyed to wrong account

Accrual and claim paths keying rewards by different addresses, or caller vs recipient confusion

_Area: DeFi accounting and math bugs. Seen in 3 disclosed reports; latest 2026-02-05. Updated 2026-10-24._

## How it works
Rewards are credited to one account but read back under another. The accrual path writes a balance keyed by the beneficiary (recipient, trader, or the account actually credited), while the claim or withdrawal path reads a different key: `msg.sender`, an intermediate contract, or a debt view with inverted semantics. The assumption that breaks is that "the address we write to" equals "the address we read from." When they diverge, the rightful earner sees zero and either nothing or the wrong party is paid.

## Where it shows up
- A reward function reusing a debt/balance helper whose direction (originated-here vs executed-here) differs from the reward intent [E1](https://bugbountylibrary.com/r/sherlock%3A2025-05-lend-audit-contest%3AH-12.md)
- `msg.sender` used as payout recipient inside a hook chain that crosses contracts [E2](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-17.md)
- Accrual mapping keyed by `recipient` but withdrawal reading `msg.sender`, often with a caller-only guard [E3](https://bugbountylibrary.com/r/c4%3A2021-04-marginswap%3AH-08.md)
- Any reward/balance helper whose name suggests one account but whose internals aggregate a different one

## How to review
For each reward or balance, trace the exact key used at every write and every read. The invariant: the key that accrues a balance must be identical to the key that claims it, and the recipient variable must be the credited account, not the caller. Check that reused helpers have matching directional semantics: confirm the helper aggregates the same account set the reward intent targets [E1](https://bugbountylibrary.com/r/sherlock%3A2025-05-lend-audit-contest%3AH-12.md). In hook chains, confirm the inner call's `msg.sender` is not mistaken for the original user [E2](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-17.md). On withdrawal functions, treat a `msg.sender`-based guard as a red flag that caller and beneficiary may differ [E3](https://bugbountylibrary.com/r/c4%3A2021-04-marginswap%3AH-08.md).

## Variants seen
- Wrong debt view: `crossChainBorrows` vs `crossChainCollaterals` inverts who earns [E1](https://bugbountylibrary.com/r/sherlock%3A2025-05-lend-audit-contest%3AH-12.md)
- Intermediate contract as recipient: LaunchPad receives user rewards during token transfers [E2](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-17.md)
- Accrual/withdrawal key mismatch plus reporter-only guard blocks all claims [E3](https://bugbountylibrary.com/r/c4%3A2021-04-marginswap%3AH-08.md)

## Impact and severity
Rewards are lost, misdirected, or permanently unclaimable. Severity is high when funds are stranded or paid to the wrong party [E2](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-17.md)[E3](https://bugbountylibrary.com/r/c4%3A2021-04-marginswap%3AH-08.md); the wrong-helper variant silently zeroes rewards for a whole class of users while paying another [E1](https://bugbountylibrary.com/r/sherlock%3A2025-05-lend-audit-contest%3AH-12.md). Worse when the wrong key is also guarded, making recovery impossible without a fix [E3](https://bugbountylibrary.com/r/c4%3A2021-04-marginswap%3AH-08.md).

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2025-05-lend-audit-contest%3AH-12.md
- E2: https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-17.md
- E3: https://bugbountylibrary.com/r/c4%3A2021-04-marginswap%3AH-08.md