Calibration request: Uniswap V3 fee-base USD when dex.trades.amount_usd follows the output leg

[six-decimals]

TL;DR: For at least one Uniswap V3 pool, dex.trades.amount_usd follows the output leg of the swap. That's a perfectly valid trade valuation — but any downstream fee model that uses it as the input-token fee base inherits large errors. I'd like to confirm the intended semantics of the field.

Questions

1. When both legs of a trade have prices, which leg is intended to populate dex.trades.amount_usd?
2. Is amount_usd intended as a general trade valuation, rather than a fee-bearing-leg valuation?
3. Should downstream fee models compute input-side USD separately when the protocol charges fees in the input token?
4. Would leg-provenance documentation, or a QA test for extreme leg divergence, be useful here?

To be clear: I'm not proposing any change to the Swap events or to dex.trades.amount_usd itself. This is a question about field semantics and downstream usage.

What I found

While rebuilding Uniswap V3 fees and protocol revenue from dex.trades:

• Scope: Ethereum, Uniswap V3, UTC [2026-06-14 00:00:00, 2026-07-14 00:00:00)
• Pool: WETH/AVAIL 0x80f8143fa056a063aaeecec3323aa3426262ddb2
• 256 trades reviewed; 142 rows differ between dex.trades.amount_usd and the sold-token input-side USD value at six-decimal precision

Worst row:

Field	Value
block	25467373
tx	0xb1a43313b51512b45fc5d921838a8a6427266f4326e5d82cde7cdbe02daa3349
evt_index	18
legacy amount_usd	$1,900,384.829449
sold-token input-side USD	$6.234174
multiple	304,833.4685×

The raw source uniswap_v3_ethereum.uniswapv3pool_evt_swap checks out: amount0/amount1 reconcile with the decoded WETH output and AVAIL input for both material rows. So the data isn't wrong — the question is which leg the field is meant to carry.

What I did on my side

I applied a targeted metric-layer repair to the 142 accepted keys only:

fixed_fee_base_usd = token_sold_amount × sold_token_minute_price_usd

Every other row keeps its legacy fee base, and a regression query proves the remaining 3,105,739 rows are unchanged at six-decimal precision.

Evidence

• Before: https://dune.com/queries/7992111/
• Diagnosis: https://dune.com/queries/7992273/
• Affected rows: https://dune.com/queries/8072957/
• Fixed model: https://dune.com/queries/8075341/
• Regression: https://dune.com/queries/8080408/
• GitHub package: https://github.com/six-decimals/onchain-data-portfolio/tree/main/01-fee-base-fix

[BhariGowda]

Great investigation. The core finding is correct and the fix approach is sound.

On your questions:

1. Which leg populates amount_usd?
   In Uniswap V3, dex.trades.amount_usd is typically derived from
   whichever leg has a more reliable price feed at query time — usually
   the output token if it's a major asset (WETH, USDC, USDT). There's
   no strict guarantee it follows the input/fee-bearing leg.

2. Is it a general trade valuation?
   Yes. amount_usd is meant as trade size estimation, not fee-base
   valuation. It was never designed to be "input-token USD value."

3. Should downstream fee models compute input-side USD separately?
   Absolutely yes especially for pools where the input token is
   illiquid or low-cap (like AVAIL here). Your approach:
   fixed_fee_base_usd = token_sold_amount × sold_token_minute_price_usd
   is exactly the right fix.

4. Leg-provenance docs + QA test?
   Both would be valuable. A QA test flagging rows where
   abs(1 - amount_usd / input_side_usd) > 0.1 (>10% divergence)
   would catch this class of issue early.

On the 304,833x multiple:
This is a classic low-liquidity/low-price token issue. AVAIL was
likely priced near zero relative to WETH at that block, so the output
leg (WETH) inflated amount_usd massively vs the actual input value.

Your regression proof on 3.1M unchanged rows is solid. Clean fix.

[six-decimals]

Thanks for the detailed answers, this clears up the leg provenance question that started the whole investigation.

Agreed on the QA test. A 10% divergence check would have flagged the WETH/AVAIL pool right away. I might write it up as a dbt test when I have time, will follow up here if I do.

[BhariGowda]

Sounds good a dbt test would be a clean way to productize
this check. If you do write it up, something like:

tests:

• name: fee_base_divergence_check
  model: dex_trades
  config:
  severity: warn
  expression: |
  abs(1 - amount_usd / nullif(input_side_usd, 0)) > 0.1

Would flag the outliers without breaking the pipeline.
Would be useful across all V3 pools, not just WETH/AVAIL.

[six-decimals]

Thanks, this sketch helps a lot. I will turn it into a proper test and open a PR. The repo asks for a [CONTRIBUTION] issue first, so I will start there. This is my first PR in this repo. Will tag you when it is up.

[six-decimals]

Thanks again for the suggestion. Opened the contribution issue for the dbt test here: #9914