# Royalty and refund misrouting

Recipient resolution that can be flipped by attacker-controlled data or diverges between parallel payout paths

_Area: DeFi accounting and math bugs. Seen in 3 disclosed reports; latest 2025-07-03. Updated 2026-10-29._

## How it works
Payout code decides *who* gets money from a value that is not trustworthy or not consistent. Either a privileged flag is derived from an attacker-writable registry (any recipient matching the seller is treated as "creator"), or two related percentage/owner sets drift apart so the payout math uses stale or partial data. The assumption that breaks: that the recipient identity and the split used for validation are the same data used for payment.

## Where it shows up
- A boolean like `isCreator` computed by comparing an address against a list the caller can edit (royalty registry, override list).
- Payout branches that zero one party's share when a flag flips.
- Two stored percentage sets: a global allocation and a per-address distribution, validated in one place and paid in another.
- Parallel entry points (single vs batch claim) with different recipient-resolution logic.
- Special-case owner remapping (escrow, delegation, AVM/original-owner) present in one path only.

## How to review
- For every payout, trace the recipient from source to transfer. Confirm the identity used for payment is the same value used for authorization, and cannot be set by the payer right before the call.
- Invariant: sum of all payouts equals the price minus fee, and each party's share is derived from data validated in the same transaction.
- Invariant: batch and single paths resolve recipients identically; diff them line by line.
- Check that per-address percentages are re-validated against the current allocation on every payout, not just at acceptance.

## Variants seen
- Attacker sets seller as royalty recipient, flipping `isCreator` and diverting all revenue to creator [E1](https://bugbountylibrary.com/r/c4%3A2022-02-foundation%3AH-02.md).
- Stale per-address percentages paid out under a new allocation, allowing up to double payout [E2](https://bugbountylibrary.com/r/c4%3A2023-10-nextgen%3AM-01.md).
- Batch claim omits original-owner remap, paying the escrow/AVM contract instead of the user [E3](https://bugbountylibrary.com/r/c4%3A2025-05-blackhole%3AM-04.md).

## Impact and severity
Revenue diverted from the rightful owner to zero [E1](https://bugbountylibrary.com/r/c4%3A2022-02-foundation%3AH-02.md), double payout draining funds [E2](https://bugbountylibrary.com/r/c4%3A2023-10-nextgen%3AM-01.md), rewards sent to the wrong contract and lost to users [E3](https://bugbountylibrary.com/r/c4%3A2025-05-blackhole%3AM-04.md). Severity rises when the misrouted party is attacker-controlled and the trigger is a single pre-sale transaction.

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2022-02-foundation%3AH-02.md
- E2: https://bugbountylibrary.com/r/c4%3A2023-10-nextgen%3AM-01.md
- E3: https://bugbountylibrary.com/r/c4%3A2025-05-blackhole%3AM-04.md