Closed henridf closed 3 years ago
Added getTransfers, and saw via some test queries that this can return large numbers of transfers (e.g. 0xb1 has ~420 uniswap swaps, but ~13000 transfers). Issuing one query per transfer (to find the potential follow-on Swap in that block) will be way too slow (and expensive).
An alternative might be to filter on a list of e.g. the top 1000 tokens in Uniswap. TBD how much that would filter down, but worth trying out.
An alternative might be to filter on a list of e.g. the top 1000 tokens in Uniswap. TBD how much that would filter down, but worth trying out.
Am guessing that actually a much smaller number than 100 should be fine (10? 100?) because sandwiching a trade that is token->(token or eth) requires having enough of the input token at hand, which less likely to be the case (with exceptions for higher-volume tokens, whcih may change over time, etc).
An alternative might be to filter on a list of e.g. the top 1000 tokens in Uniswap. TBD how much that would filter down, but worth trying out.
Also, we can use all the tokens we've discovered in the pool tracker.
Right now, we find
swapExactTokensForTokens
andswapExactETHForTokens
, but notswapExactTokensForEth
. We're missing those because we use the swap event, and on that direction, both addresses in the event are those of the router. Whereas in the ETH->token direction, one address is the user wallet.Looking at the logs for a token->ETH transaction,
Transfer
log seems like what we need.Ideally we should use the same scheme for both directions ... tbd if that will work.