Methodology

There are several methods that can be used to identify swap pairs and their respective tokens.

Lets discuss which are most useful in which scenario:

Sushiswap

Sushiswap is a decentralized exchange that has been created as a fork of Uniswap a few years ago.

Since then it implemented many new features that Uniswap does not provide. SUSHI staking, Kashi lending, Miso token launchpad just to name a few.

Besides Ethereum Sushiswap has been deployed to other EVM-Chains and also to major L2 scaling solutions for Ethereum.

Two of which are

- Binance Smart Chain

- Avalanche

1. PairCreated Event

Each time a new Sushiswap swap pair contract is created through the factory contract a PairCreated event is emitted.

Event definition on Github |

Example transaction events on BscScan |

Example transaction events on Snowtracer

This method works well if a full copy of the blockchain is available and you can query past events.

If there is no blockchain copy available this method is not very efficient as it requires you to get a copy of the chain.

Using a event listener available in node rpc endpoints this can be used to automatically label newly created contracts as Sushiswap pairs.

3. Factory Contract State

Apart from emitting a PairCreated event the factory contract also saves the index and address of each pair.

This data can read through the RPC endpoints used by wallets. There usually are several rpc providers available which you can query for free for every major blockchain / L2.

I am using:

• https://bsc-dataseed.binance.org for BSC
• https://api.avax.network/ext/bc/C/rpc for Avalanche

Instead of doing it fully manual I decided to just use a Web3 library, the one for my favorite language (C#) is NEthereum.

Now the only missing puzzle piece is the address of the factory contract which can be found within the Sushiswap Sdk on Github.

The application I wrote can be found here. It can be easily adjusted to get the same information for other evm chains that have an explorer with the same API.

For ease of use it exports the data to both a CSV and a JSON representation.

This method is well suited if you only care about the current pairs. But if new pairs get added the application will need to be reran.

Another thing to note is that it will send a large amount of requests to the RPC provider which will trigger the ratelimit a few times causing slowdowns.

Running your own node and connecting to the RPC provided by that will greatly improve the execution speed.

Avalanche

Binance Smart Chain

2. Sushiswap Analytics API

While manually reading the data from the blockchain and calculating volumes and liquidity you could also just take the easy way out and use the analytics provided by Sushiswap for their own analytics website.

Those are usually provided at

https://app.sushi.com/api/analytics/pairs/$chainId

The chainIds are

• Avalanche : 43114
• Binance Smart Chain : 56

This approach is not very flexible, you have to work with what you get from the endpoints. But as data on that endpoint is very detailed, including everything from contract and token addresses, symbols and names, liquidity and volume this should be sufficient most of the time.

Recommended for Swap Pairs!

Methodology

Unfortunately its not as easy to identify Kashi pairs as it is to identify swap pairs.

• There is no analytics endpoint provided for kashi pairs :sob:
• Instead of a dedicated factory contract kashi pairs are deployed through bentobox. The bentobox contract will not save the addresses to all kashi pairs

This leaves us with only one method for identifying Kashi pairs!

LogDeploy event

Each time a Kashi pair is created a LogDeploy event is emitted in the BentoBox contract. (Example Transaction)

Filtering for the origin being the BentoBox contract is important as some cauldron contracts seem to be emitting an event with the same topic0.

Both the master contract and the clone kashi pair address are part of the event data.

While the flipside tables do store those events, they are still in lite mode. Therefore most of those events are not actually included in the data!

But there is an alternative available: The APIs provided by chain explorers (BSCScan and Snowtracer)

Using that API you can filter for all events from a source address & containing a certain topic0.

Having those kashi pair addresses we can use the node rpc api to read the asset, collateral erc20 contracts and then read the symbol, name, decimals from those contract respectively.

I have added that mechanism to the tool I created for the swap pairs.

The application I wrote can be found here.

Results

Those results have been generated by the third method discussed above, then uploaded to Github Gist.

You can easily clone the application from method 3 from Github and generate the same / updated results yourself.

Binance Smart Chain (via BscScan)

Avalanche (via SnowTrace)

Results

Those results have been generated by using the application I wrote (see above)

You can easily clone it from Github yourself and generate the same / updated results yourself.

Binance Smart Chain (via BscScan)

Avalanche (via SnowTrace)