# Wrong trading pricing calculations

Agent spams near-zero-size orders at arbitrary prices; each trade counts equally in hourly average, skewing funding rates and fair price.

- Payout: Audit contest
- Severity: high
- Program: Tracer
- Found by: 0xsanson
- Disclosed: 2021-09-16
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-06-tracer-findings/issues/119
- Library page: https://bugbountylibrary.com/r/c4%3A2021-06-tracer%3AH-01
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:high technique:source-review vuln:business-logic vuln:oracle-manipulation

**Target:** Pricing contract / Trader.executeTrade
**Root cause:** hourlyTracerPrices[currentHour] averages prices by counting each trade as 1 regardless of fillAmount, so many tiny trades at an arbitrary price dominate the average.
**Steps:**
1. Create many orders at an arbitrary price with near-zero amount (no large funds needed).
2. Pair orders with a second account and call `Trader.executeTrade`.
3. Each order invokes `Pricing.recordTrade` recording the arbitrary price.
4. All trades in same hour skew `hourlyTracerPrices[currentHour]` toward attacker price.
5. Skewed average feeds `fundingRates` and `fairPrice`, manipulating the market.
**How found:** Code review of Pricing.recordTrade averaging logic: noticed each trade increments count by 1 rather than by fillAmount, making the average weight trade count not volume.
**Exploitation:** Attacker uses two accounts to self-match many near-zero-size orders at a chosen price within one hour, biasing the hourly average used for funding rates and fair price.
**Insight:** When an oracle/average weights by trade count instead of volume, dust trades become a cheap manipulation vector; check whether the averaging denominator is fillAmount or a fixed increment.