# Users can avoid paying any fees when using ERC20EnabledLooksRareAggregator for Seaport

SeaportProxy ignores tradeData order.price for ERC20 orders, letting users set price to zero and skip aggregator fees.

- Payout: Audit contest
- Severity: medium
- Program: LooksRare
- Found by: ronnyx2017
- Disclosed: 2023-03-21
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2022-11-looksrare#m-04
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-looksrare%3AM-04
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:business-logic vuln:fee-bypass

**Target:** SeaportProxy / ERC20EnabledLooksRareAggregator (Solidity contracts)
**Root cause:** SeaportProxy.execute uses the Seaport order's own token amount rather than the tradeData order.price, and never asserts the two are equal, so the fee computed from order.price can be zeroed.
**Steps:**
1. Build TradeData for SeaportProxy with two ERC20 (USDC) BAYC orders and maxFeeBp=250.
2. Set tradeData[0].orders[0].price = 0 while leaving the underlying Seaport order intact.
3. Compute totalPrice excluding the 250bp fee for order 0 and approve erc20EnabledAggregator for that amount.
4. Call erc20EnabledAggregator.execute(tokenTransfers, tradeData, buyer, true); both NFTs transfer but no fee is charged on order 0.
**How found:** Code review of SeaportProxy.execute noting order.price is used for fee math but not validated against the actual Seaport token amount.
**Exploitation:** Attacker submits an aggregator trade with order.price=0 for one order; Seaport still fills at the real order amount, but the aggregator's fee calculation based on order.price yields zero, so the protocol fee is never collected.
**Insight:** When an aggregator computes fees from a caller-supplied price field but executes against a separate on-chain order amount, check whether the two are ever cross-validated; mismatched price fields are a classic fee-bypass vector.