Uniswap V4/V3 Multi-Pool Arbitrage
Part I: Smart Contract Architecture
We’ve spent the last month uncovering techniques for two-pool arbitrage with at least one Uniswap V4 pool.
My final rabbit hole for the series is extending the bot to allow arbitrage across multiple V4/V3 pools. But mixing the V4/V3 callbacks together creates considerable complexity. I covered this before sharing the V4/V3 project.
The Goal
In general, I’ve been pleased with allowing V3 swaps to perform “self-payment” inside their callback by calling take() at the PoolManager. This allows the execution contract to avoid intermediate custody of forward tokens, minimizing gas costs.
However, we cannot always assume that the V3 swap can be paid by an in-scope V4 swap. Sometimes multiple V3 swaps must be chained together, and the deposit required to pay for a swap may not be available at the time of a particular callback.
This discussion will outline a possible way to implement this functionality. Testing will be necessary, and depending on how it performs I might scrap it and take an alternate route.
I want to combine the recursive callback execution of the V4/V3 bot and the dynamic swap amount model from the multi-pool V4 bot.
The contract must be able to accommodate multiple pools of either type, provided that the sequence is valid (assuming that a forward token cycle exists through all pools without gaps or repeats).