Gauntlet proposes to conduct and produce research to facilitate measuring the efficacy of different hook constructs in Uniswap V4.
Building off our prior research and leveraging our proprietary modeling SDK, Gauntlet will build an optimization and algorithmic modeling framework for Uniswap developers and community participants to compare hooks. Of particular importance in this proposal are simple proof-of-concept code snippets that will help developers evaluate hook designs and easily compare assumptions to make actionable decisions from.
Uniswap is the largest automated market maker (AMM) within decentralized finance, having processed over $1T (notional) worth of swaps since inception in 2018. The protocol has evolved numerous times, with Uniswap V2 improving the ability to route transactions across multiple pools and Uniswap V3 allowing liquidity providers to control their exposure to trades more precisely. These upgrades have been crucial to scaling the protocol, both in terms of the liquidity held by the protocol and the number of assets it can service.
Uniswap V4 hooks provide a way for liquidity held within pools to subscribe to extra covenants when used for executing trades. These extra covenants are general in nature and can cause the execution quality of a trade to differ from stock Uniswap V3-style execution. One of the most promising applications is utilizing hooks to provide extra protections for LPs from toxic flow. However, one aspect of V4 hooks that has not been fully elucidated is how it changes routing and aggregation for end users (e.g. swappers).
While AMMs can often be inefficient (in a pricing sense) relative to order books, one benefit they have is the ability to aggregate and route liquidity across multiple AMMs. This means that a single trade from an asset A to an asset B can be routed atomically through multiple paths, e.g. a trade from A → C → B plus a trade from A → D → E → B. The ability to reuse liquidity across multiple pools to atomically satisfy a single trade has helped AMMs be competitive with order books over time. There are a number of routers that compute optimal routes of trades for users, such as the Uniswap Labs router, 1inch, and Matcha.
From a theoretical lens, the reason that routing over AMMs is easier than that of order books is that a) blockchains can enforce atomicity of trades (e.g. via flash loans) and b) the routing problem is a convex optimization problem. The two works that write out the precise optimization problem for routing over networks of AMMs are:
[1] Optimal Routing for Constant Function Market Makers (Angeris, Evans, Chitra, and Boyd, EC 2022)
[2] An Efficient Algorithm for Optimal Routing Through Constant Function Market Makers (Diamandis, Resnick, Chitra, Angeris, FC 2023)
Briefly, both works focus on representing the optimal routing problem as a particular graph algorithm that can be viewed as a flow problem on a hypergraph or a bipartite graph. When writing this as a problem over the bipartite graph, one can show that the convexity properties of CFMM invariant functions are preserved and that the routing problem is itself convex. When one adds in gas estimation, the problem does involve a mixed integer linear program which can be solved using standard solving packages. The second paper specializes the results of the former to ensure that bounded liquidity pools, like those of Uniswap V3, can be routed over efficiently.
Uniswap V4, however, presents a challenge to the existing routing and aggregation paradigm. A major reason is that V4 hooks effectively add extra constraints to the routing optimization problem. For instance, if I have a V4 hook that doesn’t allow non-KYC’d addresses to trade with a pool (e.g. using Coinbase attestations), then one has to add constraints that don’t allow any flow across a graph edge if there is a KYC address involved. This type of constraint is inherently combinatorial in nature and can cause the optimization to take significantly longer to solve and/or yield an infeasible solution.
From this setup, there are several questions that naturally arise, and which are the motivation for this proposal. We group these questions as mathematical (focused around the underlying optimization problem at hand) or algorithmic (focused around implementation details and impact on developers):
Our proposal aims to answer these questions.