# _execute_transfer wrong order of operations, will first apply diff and then check with applying the diff

_execute_transfer applied the sender's collateral diff before health validation, so validation re-applied the diff and could wrongly revert a healthy transfer.

- Payout: Contest reward
- Severity: high
- Program: Starknet Perpetual
- Credited: EPSec
- Disclosed: 2025-06-18
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-03-starknet-perpetual#h-02
- Library page: https://bugbountylibrary.com/r/c4%3A2025-03-starknet-perpetual%3AH-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Perpetuals core contract transfer flow (Cairo)
**Root cause:** _execute_transfer calls positions.apply_diff on the sender before _validate_healthy_or_healthier_position, and validation applies the same position_diff again, double-counting the debit.
**Steps:**
1. Read core.cairo L959-L988: apply_diff(sender, -amount) then apply_diff(recipient, +amount) then _validate_healthy_or_healthier_position(sender, position_diff_sender).
2. Note validation internally applies position_diff to the snapshot, so the sender's debit is counted twice.
3. Repro: open a trade so sender has a healthy position, then call transfer_request + transfer of an amount that is healthy once but unhealthy when doubled.
4. Observe _validate_healthy_or_healthier_position reverts, blocking a legitimate transfer.
5. Fix: validate sender health against the pre-diff snapshot before any apply_diff.
**How found:** Code reading of the transfer function's ordering: noticed apply_diff precedes validation while validation itself applies the same diff, implying double application.
**Insight:** When a validation helper takes a position_diff and applies it internally, check whether callers already mutated state with that diff — double-application of diffs is a recurring ordering bug in perp/accounting code.