How To Escape Uniswap Callback Hell

lock it, code it, call it, swap it, sync it, take it, swap — unlock it

Phone’s ringing, Dude

The previous project demonstrated a V4/V2 arbitrage strategy.

Project: Uniswap V4/V2 Two-Pool Arbitrage Bot

In fact, most of the complexity of the path finding and smart contract was due to accounting and handling of mixed-profit tokens.

After understanding and dealing with that difference, the implementation of the pool swaps was quite straightforward. This is due largely to the Uniswap V2 pool’s design.

Uniswap V2

The V2 pool tracks its current reserves in storage, which gives it flexibility with respect to its swap accounting. If you review the UniswapV2Pair.sol contract, you’ll find that the token reserves are loaded from storage immediately after swap is called. After the requested transfer(s), the pool performs two ERC-20 balanceOf calls to check the new reserves for both tokens, and records them again to storage if they satisfy the invariant.

This flexibility means that you can transfer the input to the pool before calling swap and it will all line up. The well-known V2→V2→V2 continuous swap can be optimized by simply instructing each pool (except the last) to send the swap output to the next one.

Uniswap V3

Unfortunately for us, the design of Uniswap V3 eliminated this one weird trick.

In its place, a Uniswap V3 pool implements a system whereby the swap must be performed by a smart contract with a formatted callback that performs payment for the requested swap.

I have covered the Uniswap V3 swap callback before, so please review it if unfamiliar.

Uniswap V3 — Swap Callback

The source of UniswapV3Pool.sol reveals how tightly bound the callback is to the repayment: