dalechyn / arbitrageur Goto Github PK

100% of the code written in smart contract was written purely in order to make it work.

After #6 is done, a huge optimization is needed.

Convict should take:

1. Base Token address
2. First Pool Type (V2|V3)
3. Second Pool Type (V2|V3)
4. Fees of first pool | second pool (numerator, denominator)

Fetcher

The Fetcher should be only aware of fetching pools and should not balance them in any way.

• Move the next logic to Balancer as it should be responsible for guessing the direction of trade and of its amount.
  https://github.com/h0tw4t3r/arb/blob/68bea4ea8f90277f26a583a570cd930f97d7bd64/src/fetcher/index.ts#L47-L97
• Create a helper function that handles UniswapV2-like fetching with factory address and fees as parameters
• Create a Fetcher class and split methods so they are not too big.

Balancer

• p{1,2} notations should be renamed to from and to
• DEXType should be stored in the SupportedPoolWithContract, also think of renaming it as well
• Direction selection and pools selection should take place in Balancer constructor
• BalanceResult->BalancerResult

Main

Fetcher and Balancer creation should take place in the main function.

After #6 and #7 are done, the contract is ready for deployment.

To save some gas an efficient address has to be found [1].

I found a tool that can help with that - https://github.com/johguse/ERADICATE2

References:

• [1] https://medium.com/coinmonks/on-efficient-ethereum-addresses-3fef0596e263

https://blocks.flashbots.net/

We need to find the GraphQL interfaces to scan the tokens across different swaps.

It's crucial to have all GraphQL statistics for all available DEXes for arbitrage since massive liquidity change can start on any of those.

Obv the title

Obv the title

Currently, there is no logic to jump through DEXes to find profitable opportunities.

https://github.com/h0tw4t3r/arb/blob/b36b6fba64a6acb3b8b686a1fd4357f7fe7c504f/src/fetcher/index.ts#L29
https://github.com/h0tw4t3r/arb/blob/b36b6fba64a6acb3b8b686a1fd4357f7fe7c504f/src/fetcher/index.ts#L36-L45

Hence, some big infrastructure choices are needed to be discussed.

We have several ways to manage the search process.

Option 1: Scale the provider

We can take the power of ethProvider.on('block', <handler>) in order to hook a very large amount of handlers that is equal to DEX_COUNT * TOKENS_COUNT.

As of now, we added 3 DEXes and 6 tokens which would already spawn and would result in 18 block listeners.

Knowing the nature of Event Loop, the more listeners we would have, the more the overall process will slow down. A slight reminder we have around 10-12 seconds to push the data until a new block is produced.

From what I remember, there are around 5-6 DEXes which we can easily connect (as they are UniswapV2 clones), and considering we would have #3 implemented, Just with 1000 tokens to be observed (which is a super-small amount), we would have around 5k-6k listeners on a single provider. Such an amount could flood the Event Loop making it slower than the next option.

Option 2: Scale the nodes, not the code

We can have multiple nodes of the bot running on the same machine, scaled by workers basically.

It will ease the load on every worker's Event Loop but could overload the RPC. Chances of using Alchemy are decaying as we go deeper.

Option 3: Use SaaS to deploy a worker on-demand with a single pair to be observed across all DEXes

A mix of Option 1 and Option 2. If that would be possible with linking to an ETH node, fast enough that would be a self-balancing solution, considered of #3 with automatically token addition when certain liquidity in USD has reached, and token deletion.

Just as #8, method names also need optimization.

The more leading zeroes we have - the more gas-efficient the call is.

Basically, we can even write a small tool, or find one. Just small mining over keccak256 with salt in the method name is needed to find the best.

And if we match the ABI, we can even use https://www.4byte.directory

As of now, we have V3-V2 arbitrage logic, but don't have V2-V2.

Basically, the methods would replicate the logic themselves, so a single method for handling such can be used.

Reference to use: https://github.com/Haehnchen/uniswap-arbitrage-flash-swap/blob/main/contracts/Flashswap.sol