# Claim liquidation escrow

Liquidator self-trades between two owned accounts to generate slippage, then claims the liquidation escrow reimbursement for that slippage.

- Payout: Audit contest
- Severity: medium
- Program: Tracer
- Found by: gpersoon
- Disclosed: 2021-09-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-06-tracer-findings/issues/2
- Library page: https://bugbountylibrary.com/r/c4%3A2021-06-tracer%3AM-11
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:accounting-error vuln:business-logic

**Target:** Trader.executeTrade / Liquidation.claimReceipt
**Root cause:** executeTrade is permissionless and claimReceipt reimburses slippage without verifying the trade was legitimate or that the claimant didn't control both sides.
**Steps:**
1. Create a second account controlled by the liquidator.
2. Set up a complimentary trade in the second account that produces large slippage when executed.
3. Call `executeTrade(makers, takers)` to execute the trade between the two owned accounts; slippage is harmless since both sides are owned.
4. Call `claimReceipt(receiptId, orders, traderContract)` with the executed order's receiptId within the required period (e.g. 15 minutes).
5. Receive the liquidation escrow reimbursement for the self-inflicted slippage.
**How found:** Observed that executeTrade is callable by anyone and claimReceipt reimburses slippage without checking trade legitimacy, enabling a self-dealing trade to manufacture a claimable loss.
**Exploitation:** Attacker controls both maker and taker accounts, executes a trade with large slippage via permissionless executeTrade, then claims the escrow reimbursement for that slippage within the claim window, extracting escrow funds.
**Insight:** When a protocol reimburses slippage or losses, check whether the claimant can control both sides of the trade that generated the loss; permissionless trade execution plus loss reimbursement is a self-dealing payout primitive.