Rewrite It in Rust: Pool State & Path Solver

This entry builds on the theoretical concepts explored in the Numerical Optimization series. If you didn’t read those, shame on you! But for your convenience, here they are again:

A given liquidity pool can be expressed as a tuple of immutable identity values and mutable state values.

For example, a Uniswap V2 pool consists of an identity:

and a state:

Each pool is tracked by a Bot instance (see Part II), and the state is updated whenever the appropriate event listener observes an event that modifies this mutable state, and instructs the bot to apply the state transition function to the pool.

When we want to perform calculations against this state, we will ask the bot to evaluate the request against that pool’s state. Under the hood, the state is collapsed into a simplified data structure that arranges the reserves based on the input and output direction:

This struct has an impl block for a swap method that replicates the Uniswap V2 formula:

The user-facing bot wraps this up with a generalized function that can perform a swap calculation against different pool types defined in the PoolEntry enum:

With this type-erased structure, swap calculations can be chained together as part of an arbitrage path and optimized by a dedicated solver. The solver does not care about the identity of the pool, its tokens, what position they are in, or the contents of the rollback journal. It only cares about the reserves associated with the token going in and out.

I have created a solver called UniswapEngine that handles Uniswap-style paths using these intermediate hops. It holds a reference to a Bot, which in turn holds the individual pools.

It implements several solver functions that operate on different kinds of paths. For example, a V2-only solver based on the closed-form Möbius solution is very simple. It takes an IntHopState array generated from the pools, then evaluates its 2x2 matrix: