more correct user volume

[max-morrow]

Tried to make a more correct user volume.

• The user volume is the maximum of the amounts (in USD) sold and bought, that is, it is the amount (in USD) that the user owned/began to own after the exchange/interaction with protocol, that is, this is how much user money has passed through the protocol.
• Most often, the amount that the user sold (in USD) is more than the amount that he bought (in USD).

[dune-eng]

Workflow run id 10490239773 approved.

[dune-eng]

Workflow run id 10490240084 approved.

[dune-eng]

Workflow run id 10504866738 approved.

[dune-eng]

Workflow run id 10504866989 approved.

[dune-eng]

Workflow run id 10507321559 approved.

[dune-eng]

Workflow run id 10507321692 approved.

[max-morrow]

@jeff-dude suggestions are ready to review

[jeff-dude]

thanks for raising. this has quite a large impact downstream, so we will want to test this in CI extensively.

do you have context around how you ran into this? maybe some example tx's or anything other existing data/queries to share?

i think it'd also be good to take CI table output and compare to prod table. maybe something along the lines of new CI amount_usd minus prod amount_usd, grab absolute of that value, see largest discrepancies

[0xBoxer]

This is great stuff @max-morrow, thanks for this contribution!

I think we should merge this @jeff-dude

I'll just drop this GPT summary here so we are all on the same page:

PR Summary:

This change improves the calculation of amount_usd by introducing a more robust and systematic approach that prioritizes trusted token values while ensuring that the largest transaction value is always captured.

Key Changes:

1. Prioritization of Trusted Tokens:

   • The updated logic uses the GREATEST function to compare token values, ensuring that trusted tokens are prioritized.
   • If a token is trusted, its value is considered for the calculation. If both tokens are trusted, the higher value between the sold and bought tokens is selected.

2. Fallback to Raw Values:

   • If neither token is trusted, the logic falls back to the raw token values using a second GREATEST function to ensure the calculation still captures the higher value between the sold and bought tokens, regardless of trust status.

3. COALESCE for Efficient Selection:

   • The COALESCE function ensures that if the first comparison (trusted values) returns a non-null result, it is used. Otherwise, it defaults to the second comparison (raw values), maintaining completeness in cases where no trusted tokens are involved.

Result:

This modification removes the previous arbitrary selection between bought and sold tokens based on contract_address and instead systematically selects the larger side of the transaction, with trusted prices always prioritized when available.

[jeff-dude]

fyi @couralex6
we will be merging this, and i can combine with same time as the merge to remove arbitrary cutoff date for prices model. this will change values in amount_usd, so we will want to ensure we pull all of history out of this forward

[jeff-dude]

fwiw, this is the type of testing i was referring to on this change:

with
  prod as (
    select
      blockchain,
      tx_hash,
      evt_index,
      sum(amount_usd) as sum_amount
    from
      dex.trades
    where
      block_date >= date '2024-09-01'
    group by
      blockchain,
      tx_hash,
      evt_index
  ),
  ci as (
    select
      blockchain,
      tx_hash,
      evt_index,
      sum(amount_usd) as sum_amount
    from
      test_schema.git_dunesql_8ae05dc_dex_trades
    where
      block_date >= date '2024-09-01'
    group by
      blockchain,
      tx_hash,
      evt_index
  ),
  combined as (
    select
      prod.blockchain,
      prod.tx_hash,
      prod.evt_index,
      prod.sum_amount as prod_amount,
      ci.sum_amount as ci_amount,
      abs(prod.sum_amount - ci.sum_amount) as diff
    from
      prod
      inner join ci on prod.blockchain = ci.blockchain
      and prod.tx_hash = ci.tx_hash
      and prod.evt_index = ci.evt_index
  )
select
  *
from
  combined
order by
  diff desc
limit
  100

there seem to be some large differences, but i haven't had the change to dig into the why quite yet.