[BUG] uniswap v2 missing swaps
jeff-dude opened this issue · comments
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?
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.
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-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
andtoken_sold_address
in tests associated with each project-level spell that feeds into the sector-level spell. fordex.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 theamount_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
Hey folks, HNY! How can we help move this fwd?
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
fyi, i've raised internally and we're looking into this. thank you for continued patience