[BUG] uniswap v2 missing swaps

[jeff]

Description

Swap events contain amounts in and out for both tokens 0 and 1, so we actually have two "swaps" in each event:

• Token 0 in, token 1 out
• Token 1 in, token 0 out

Most of the time, one of these swaps has empty/zero amounts, ie the trader is only swapping one token for another. However, there are some edge cases where both amounts for one of the tokens is non-zero, and both amounts for the other token are zero. eg 0x2643cc80871c4134704863b17f10901ea6d11646fc10162ff1fb504e7137c193, evt index 75

In other cases, both amounts for both tokens are non-zero eg 0x5afc81f74fbfca62c7d083cccbadd01158f65bfdb1f2c7fb24e4866c1d96e346, evt index 27

As this query shows, dex.trades only partially reflects the information present in the swap events mentioned above. This happens because the current implementation of uniswap_v2_ethereum_trades.sql assumes there is only one swap contained in the Swap event: if amount0Out == 0 the code assumes token 1 is being bought, else token 0 is being bought.

This PR addresses this limitation by extracting both swaps from the Swap event and discarding the "empty swap" that is present in the vast majority of cases.

While events like the ones in the transactions mentioned here are very much the exception, they can have significant impact in some analyses. For example, the data regarding the swap txn 0x2643cc... would lead to believe that the pool sold 50M USDC for 0 WETH when in reality the pool sold 50M USDC for 50.1M USDC.

Impacted model(s) / macro(s)

uniswap_compatible_trades.sql
uniswap_v2_ethereum_trades

Possible solution

linked PR has initial steps to resolve

open questions

• how many uniswap v2 forks are in spellbook, that feed into dex.trades, which also need resolved?
• the linked PR introduces a change to add two new unique keys for uniswap v2 -- this breaks the universal unique key assignment across all projects in dex.trades lineage. how can we write the code to avoid adding unique keys?
• how should we proceed?
  • fix only uniswap v2 & uniswap macro for new dex lineage for now, leaving out all forks?

[0xBoxer]

I am developing a method for decoding all uniswap v2 deployments on #4730 - since Uniswap v2 forks should all behave exactly the same, I am wondering if it might make sense to run with this approach and drop all decoded Uniswap V2 forks that have been manually decoded and instead add the factories to the mapping schema I have already started creating.

I am unsure about the performance implications of decoding from logs on the fly, but this would save a ton of overhead while dealing with the Uniswap v2 forks.

Finding all UNIV2 forks that are already decoded and in Spellbook should be a matter of writing a query against dex.trades.

[Markus Buhatem Koch]

the linked PR introduces a change to add two new unique keys for uniswap v2 -- this breaks the universal unique key assignment across all projects in dex.trades lineage. how can we write the code to avoid adding unique keys?

@jeff-dude Can you please elaborate on why introducing two additional keys would be an issue?

[jeff]

@jeff-dude Can you please elaborate on why introducing two additional keys would be an issue?

a few reasons:

• for these important sector-level spells, having a consistent set of unique keys in all spells that feed into it helps us ensure a level of data quality
• we use token_bought_address and token_sold_address in tests associated with each project-level spell that feeds into the sector-level spell. for dex.trades, the test helps us ensure correct bought/sold assignment in query, to prevent incorrect amounts being fed downstream (we've had this issue multiple times in the past, where the amount_usd value then gets exponentially inflated)

i'll need to take a closer look at the examples you've provided, to put a better visual on it and see what we can do here

[Markus Buhatem Koch]

Hey folks, HNY! How can we help move this fwd?

[jeff]

Hey folks, HNY! How can we help move this fwd?

let me try to dig into this early next week and see the impact on overall dex.trades lineage & see how we can implement while keeping design patterns consistent

[jeff]

fyi, i've raised internally and we're looking into this. thank you for continued patience