Skip to content
Bain Capital Crypto
  • Team
  • Portfolio
  • Insights
  • Jobs
  • Contact
  • Basics
  • Cryptography
  • DeFi
  • Hiring
  • MEV
  • Press Release
  • Privacy
  • Regulatory
  • Research
  • Uncategorized
  • Akshay Agrawal
  • Alex Evans
  • Andrew Cleverdon
  • Andrija Novakovic
  • Charlotte Kyle
  • Ciamac Moallemi
  • Eugene Chen
  • grjte
  • Guillermo Angeris
  • Haley MacCormac
  • Justin Rattigan
  • Kaley Petulla
  • Kamil Yusubov
  • Kara Reusch
  • Kevin Zhang
  • Khurram Dara
  • Kimleang Svay
  • Kobi Gurkan
  • Koh Wei Jie
  • Kshitij Kulkarni
  • Mallesh Pai
  • Mandy Campbell
  • Max Resnick
  • Michael Chagnon
  • Myles Maloof
  • Nashqueue
  • Natalie Mullins
  • Nathan Sheng
  • Nicolas Mohnblatt
  • Parth Chopra
  • Sanaz Taheri
  • Stefan Cohen
  • Stephen Boyd
  • Tarun Chitra
Ligerito: A Small and Concretely Fast Polynomial Commitment Scheme
In this note we present Ligerito, a small and practically fast polynomial commitment and inner product scheme. For the case…
05.01.25
Exploring interoperability & composability for local-first software
Check out the project at https://github.com/grjte/groundmist-syncCross-posted to my atproto PDS and viewable at Groundmist Notebook and WhiteWind. This is the third exploration connecting local-first…
  • grjte
  • Privacy,
  • Research
04.22.25
Exploring the AT Protocol as a legibility layer for local-first software
Check out the project at https://notebook.groundmist.xyzCross-posted to my atproto PDS and viewable at Groundmist Notebook and WhiteWind Some people like vim and some…
  • grjte
  • Privacy,
  • Research
04.22.25
Exploring the AT Protocol as a distribution layer for local-first software
Check out the project at https://library.groundmist.xyzCross-posted to my atproto PDS and viewable at Groundmist Notebook and WhiteWind What if private…
  • grjte
  • Privacy,
  • Research
04.22.25
CryptoUtilities.jl: A Small Julia Library for Succinct Proofs
We’re excited to open-source CryptoUtilities.jl, a collection of Julia packages built to prototype and benchmark succinct proof systems over binary…
  • Andrija Novakovic,
  • Guillermo Angeris
  • Cryptography,
  • Research
04.16.25
Public, Provable Prices
What happens when exchanges operate with a discrete clock? In our last post, we argued that blockchains have a system…
  • Theo Diamandis,
  • Khurram Dara
  • Regulatory,
  • Research
02.26.25
Perpetual Demand Lending Pools
Decentralized perpetuals protocols have collectively reached billions of dollars of daily trading volume, yet are still not serious competitors on…
  • Tarun Chitra,
  • Theo Diamandis,
  • Kamil Yusubov,
  • Nathan Sheng
  • DeFi,
  • Research
02.12.25
The Accidental Computer: Polynomial Commitments from Data Availability
In this paper, we present two simple variations of a data availability scheme that allow it to function as a…
  • Alex Evans,
  • Guillermo Angeris
  • Research
01.31.25
Manipulability Is a Bug, Not a Feature
Like a computer, a blockchain has an internal clock: the blocktime [1]. Users send the blockchain transactions which contain sequences…
  • Theo Diamandis,
  • Khurram Dara
  • Regulatory,
  • Research
01.30.25
Optimizing Montgomery Multiplication in WebAssembly
Operations on elliptic curves over large prime fields can be significantly sped up via optimisations to their underlying field multiplication…
  • Koh Wei Jie
  • Research
12.05.24
Chosen-Instance Attack
How succinct proofs leak information What happens when a succinct proof does not have the zero-knowledge property? There is a…
  • Nicolas Mohnblatt
  • Privacy,
  • Research
12.04.24
ZODA: Zero-Overhead Data Availability
We introduce ZODA, short for ‘zero-overhead data availability,’ which is a protocol for proving that symbols received from an encoding…
  • Alex Evans,
  • Nicolas Mohnblatt,
  • Guillermo Angeris
  • Research
12.03.24
ZODA: An Explainer
Data availability sampling (DAS) is critical to scaling blockchains while maintaining decentralization [ASB18,HASW23]. In our previous post, we informally introduced…
  • Alex Evans,
  • Nicolas Mohnblatt,
  • Guillermo Angeris,
  • Sanaz Taheri,
  • Nashqueue
  • Research
12.03.24
Sampling for Proximity and Availability
In blockchains, nodes can ensure that the chain is valid without trusting anyone, not even the validators or miners. Early…
  • Alex Evans,
  • Nicolas Mohnblatt,
  • Guillermo Angeris
  • Research
11.08.24
Expanding
At Bain Capital Crypto, research and investing are interlocked. Researching foundational problems has led to our most successful investments. Working…
  • Alex Evans
  • Hiring
10.29.24
An Analysis of Intent-Based Markets
Mechanisms for decentralized finance on blockchains suffer from various problems, including suboptimal price execution for users, latency, and a worse…
  • Tarun Chitra,
  • Theo Diamandis,
  • Kshitij Kulkarni,
  • Mallesh Pai
  • DeFi,
  • Research
03.06.24
Multidimensional Blockchain Fees are (Essentially) Optimal
Abstract In this paper we show that, using only mild assumptions, previously proposed multidimensional blockchain fee markets are essentially optimal,…
  • Guillermo Angeris,
  • Theo Diamandis,
  • Ciamac Moallemi
  • Research
02.13.24
Toward Multidimensional Solana Fees
A Solana transaction’s journey from user submission to block inclusion can be arduous. Even once the transaction reaches the current leader, it…
  • Theo Diamandis,
  • Tarun Chitra,
  • Eugene Chen
  • Research
01.31.24
Succinct Proofs and Linear Algebra
Abstract The intuitions behind succinct proof systems are often difficult to separate from some of the deep cryptographic techniques that…
  • Alex Evans,
  • Guillermo Angeris
  • Research
09.21.23
The Specter (and Spectra) of MEV
Abstract Miner extractable value (MEV) refers to any excess value that a transaction validator can realize by manipulating the ordering…
  • Guillermo Angeris,
  • Tarun Chitra,
  • Theo Diamandis,
  • Kshitij Kulkarni
  • Research
08.14.23
The Geometry of Constant Function Market Makers
Abstract Constant function market makers (CFMMs) are the most popular type of decentralized trading venue for cryptocurrency tokens. In this paper,…
  • Guillermo Angeris,
  • Tarun Chitra,
  • Theo Diamandis,
  • Alex Evans,
  • Kshitij Kulkarni
  • Research
07.20.23
Our Comment on The SEC’s Proposed Amendments to Exchange Act Rule 3b-16
This week, we submitted a comment in response to the SEC’s proposed amendments to Exchange Act Rule 3b-16 regarding the…
  • Regulatory
06.15.23
Opinion: A House Bill Would Make It Harder for the SEC to Argue Crypto Tokens Are Securities
The proposed Securities Clarity Act by Representatives Tom Emmer and Darren Soto would significantly reduce uncertainty for both crypto investors…
  • Khurram Dara
  • Regulatory
06.01.23
Opinion: Regulators Should Not ‘Front-Run’ Congress on Stablecoins
Growing consensus on the need for comprehensive legislation on payment stablecoins provides Congress with an opportunity to enact sensible regulation…
  • Khurram Dara
  • Regulatory
05.17.23
Our Comment on The SEC’s Proposed Custody Rule
This week, we submitted a comment in response to the SEC’s proposed custody rule, together with Dragonfly Capital, Electric Capital,…
  • Regulatory
05.09.23
A Note on the Welfare Gap in Fair Ordering
In this short note, we show a gap between the welfare of a traditionally ‘fair’ ordering, namely first-in-first-out (an ideal…
  • Theo Diamandis,
  • Guillermo Angeris
  • Research
03.27.23
An Efficient Algorithm for Optimal Routing Through Constant Function Market Makers
Constant function market makers (CFMMs) such as Uniswap have facilitated trillions of dollars of digital asset trades and have billions…
  • Theo Diamandis,
  • Max Resnick,
  • Tarun Chitra,
  • Guillermo Angeris
  • DeFi,
  • Research
02.17.23
Multi-dimensional On-chain Resource Pricing
Public blockchains allow any user to submit transactions which modify the shared state of the network. These transactions are independently…
  • Theo Diamandis
  • Basics
08.16.22
Dynamic Pricing for Non-fungible Resources
Public blockchains implement a fee mechanism to allocate scarce computational resources across competing transactions. Most existing fee market designs utilize a joint, fungible unit of account (e.g., gas in Ethereum) to price otherwise non-fungible resources such as bandwidth, computation, and storage, by hardcoding their relative prices. Fixing the relative price of each resource in this way inhibits granular price discovery, limiting scalability and opening up the possibility of denial-of-service attacks.
  • Theo Diamandis,
  • Alex Evans,
  • Tarun Chitra,
  • Guillermo Angeris
  • Basics
08.16.22
Introducing CFMMRouter.jl
We created CFMMRouter.jl for convex optimization enthusiasts, twitter anons, and Tarun Chitra to easily find the optimal way to execute…
  • Guillermo Angeris,
  • Theo Diamandis
  • DeFi,
  • MEV
04.05.22
Introducing Bain Capital Crypto
We are excited to announce Bain Capital Crypto (BCC), our first $560mm fund, and the launch of a new platform…
  • Stefan Cohen
  • Press Release
03.08.22
Optimal Routing for Constant Function Market Makers
We consider the problem of optimally executing an order involving multiple cryptoassets, sometimes called tokens, on a network of multiple constant function market makers (CFMMs). When we ignore the fixed cost associated with executing an order on a CFMM, this optimal routing problem can be cast as a convex optimization problem, which is computationally tractable. When we include the fixed costs, the optimal routing problem is a mixed-integer convex problem, which can be solved using (sometimes slow) global optimization methods, or approximately solved using various heuristics based on convex optimization. The optimal routing problem includes as a special case the problem of identifying an arbitrage present in a network of CFMMs, or certifying that none exists.
  • Guillermo Angeris,
  • Tarun Chitra,
  • Alex Evans,
  • Stephen Boyd
  • MEV
12.01.21
Replicating Monotonic Payoffs Without Oracles
In this paper, we show that any monotonic payoff can be replicated using only liquidity provider shares in constant function market makers (CFMMs), without the need for additional collateral or oracles. Such payoffs include cash-or-nothing calls and capped calls, among many others, and we give an explicit method for finding a trading function matching these payoffs. For example, this method provides an easy way to show that the trading function for maintaining a portfolio where 50% of the portfolio is allocated in one asset and 50% in the other is exactly the constant product market maker (e.g., Uniswap) from first principles. We additionally provide a simple formula for the total earnings of an arbitrageur who is arbitraging against these CFMMs.
  • Guillermo Angeris,
  • Alex Evans,
  • Tarun Chitra
  • DeFi
09.01.21
Constant Function Market Makers: Multi-Asset Trades via Convex Optimization
The rise of Ethereum and other blockchains that support smart contracts has led to the creation of decentralized exchanges (DEXs), such as Uniswap, Balancer, Curve, mStable, and SushiSwap, which enable agents to trade cryptocurrencies without trusting a centralized authority. While traditional exchanges use order books to match and execute trades, DEXs are typically organized as constant function market makers (CFMMs). CFMMs accept and reject proposed trades based on the evaluation of a function that depends on the proposed trade and the current reserves of the DEX. For trades that involve only two assets, CFMMs are easy to understand, via two functions that give the quantity of one asset that must be tendered to receive a given quantity of the other, and vice versa. When more than two assets are being exchanged, it is harder to understand the landscape of possible trades. We observe that various problems of choosing a multi-asset trade can be formulated as convex optimization problems, and can therefore be reliably and efficiently solved.
  • Guillermo Angeris,
  • Akshay Agrawal,
  • Alex Evans,
  • Tarun Chitra,
  • Stephen Boyd
  • Basics,
  • DeFi
07.01.21
Replicating Market Makers
We present a method for constructing Constant Function Market Makers (CFMMs) whose portfolio value functions match a desired payoff. More specifically, we show that the space of concave, nonnegative, nondecreasing, 1-homogeneous payoff functions and the space of convex CFMMs are equivalent; in other words, every CFMM has a concave, nonnegative, nondecreasing, 1-homogeneous payoff function, and every payoff function with these properties has a corresponding convex CFMM. We demonstrate a simple method for recovering a CFMM trading function that produces this desired payoff. This method uses only basic tools from convex analysis and is intimately related to Fenchel conjugacy. We demonstrate our result by constructing trading functions corresponding to basic payoffs, as well as standard financial derivatives such as options and swaps.
  • Guillermo Angeris,
  • Alex Evans,
  • Tarun Chitra
  • DeFi
03.01.21
A Note on Privacy in Constant Function Market Makers
Constant function market makers (CFMMs) such as Uniswap, Balancer, Curve, and mStable, among many others, make up some of the largest decentralized exchanges on Ethereum and other blockchains. Because all transactions are public in current implementations, a natural next question is if there exist similar decentralized exchanges which are privacy-preserving; i.e., if a transaction’s quantities are hidden from the public view, then an adversary cannot correctly reconstruct the traded quantities from other public information. In this note, we show that privacy is impossible with the usual implementations of CFMMs under most reasonable models of an adversary and provide some mitigating strategies.
  • Guillermo Angeris,
  • Alex Evans,
  • Tarun Chitra
  • Privacy
02.01.21
Optimal Fees for Geometric Mean Market Makers
Constant Function Market Makers (CFMMs) are a family of automated market makers that enable censorship-resistant decentralized exchange on public blockchains. Arbitrage trades have been shown to align the prices reported by CFMMs with those of external markets. These trades impose costs on Liquidity Providers (LPs) who supply reserves to CFMMs. Trading fees have been proposed as a mechanism for compensating LPs for arbitrage losses. However, large fees reduce the accuracy of the prices reported by CFMMs and can cause reserves to deviate from desirable asset compositions. CFMM designers are therefore faced with the problem of how to optimally select fees to attract liquidity. We develop a framework for determining the value to LPs of supplying liquidity to a CFMM with fees when the underlying process follows a general diffusion. Focusing on a popular class of CFMMs which we call Geometric Mean Market Makers (G3Ms), our approach also allows one to select optimal fees for maximizing LP value. We illustrate our methodology by showing that an LP with mean-variance utility will prefer a G3M over all alternative trading strategies as fees approach zero.
  • Guillermo Angeris,
  • Tarun Chitra,
  • Alex Evans,
  • Stephen Boyd
  • DeFi
01.04.21
Liquidity Provider Returns in Geometric Mean Markets
Geometric mean market makers (G3Ms), such as Uniswap and Balancer, comprise a popular class of automated market makers (AMMs) defined by the following rule: the reserves of the AMM before and after each trade must have the same (weighted) geometric mean. This paper extends several results known for constant-weight G3Ms to the general case of G3Ms with time-varying and potentially stochastic weights. These results include the returns and no-arbitrage prices of liquidity pool (LP) shares that investors receive for supplying liquidity to G3Ms. Using these expressions, we show how to create G3Ms whose LP shares replicate the payoffs of financial derivatives. The resulting hedges are model-independent and exact for derivative contracts whose payoff functions satisfy an elasticity constraint. These strategies allow LP shares to replicate various trading strategies and financial contracts, including standard options. G3Ms are thus shown to be capable of recreating a variety of active trading strategies through passive positions in LP shares.
  • Alex Evans
  • DeFi
06.01.20
Back

Optimal Routing for Constant Function Market Makers

  • Guillermo Angeris,
  • Tarun Chitra,
  • Alex Evans,
  • Stephen Boyd
12.01.21
  • Download PDF
  • Share on Twitter
  • Copy Link

Abstract

We consider the problem of optimally executing an order involving multiple cryptoassets, sometimes called tokens, on a network of multiple constant function market makers (CFMMs). When we ignore the fixed cost associated with executing an order on a CFMM, this optimal routing problem can be cast as a convex optimization problem, which is computationally tractable. When we include the fixed costs, the optimal routing problem is a mixed-integer convex problem, which can be solved using (sometimes slow) global optimization methods, or approximately solved using various heuristics based on convex optimization. The optimal routing problem includes as a special case the problem of identifying an arbitrage present in a network of CFMMs, or certifying that none exists.

Introduction

Decentralized exchanges (DEXs) are a popular application of public blockchains that allow users to trade assets without the need for a trusted intermediary to facilitate the exchange. DEXs are typically implemented as constant function market makers (CFMMs)1. In CFMMs, liquidity providers contribute reserves of assets. Users can then trade against these reserves by tendering baskets of assets in exchange for other baskets. CFMMs use a simple rule for accepting trades: a trade is only valid if the value of a given function at the post-trade reserves (with a small adjustment to account for fees collected) is equal to the value at the pre-trade reserves. This function is called the trading function and gives CFMMs their name. A common example of a trading function is the constant product popularized by Uniswap2, wherein a trade is only accepted if it preserves the product of the reserve amounts.

CFMMs have quickly become one of the most popular applications of public blockchains, facilitating several billion dollars of trading volume per day. As DEXs have grown in popularity, so have the number of CFMMs and assets offered, creating complexity for traders who simply want to maximize their utility for trading one basket of assets for another. As a result, several “DEX aggregators” have emerged to route orders across multiple CFMMs on behalf of users. These aggregators currently execute several billion dollars per month across all DEXs on Ethereum3. At the same time, CFMM platforms such as Uniswap offer software for routing orders across the subset of CFMMs they support4.

While the properties of individual CFMMs have been studied extensively (see, e.g.,15) it is more common for users to want to access liquidity on multiple CFMMs to minimize their total trading costs. In this paper, we study the optimal routing problem for CFMMs. We consider a user who can trade with multiple CFMMs in order to exchange one basket of assets for another and ask how one should perform such trades optimally. We show that, in the absence of fixed costs, the optimal routing problem can be formulated as a convex optimization problem, which is efficiently solvable. As an (important) sub-case, we demonstrate how to use this problem to identify arbitrage opportunies on a set of CFMMs. Our framework encompasses the routing problems considered in prior work67 and offers solutions in the more general case where users seek to trade any basket of assets for any other basket across any set of CFMMs whose trading functions are concave and not necessarily differentiable. When including transaction costs, we show that the optimal routing problem is a mixed-integer convex problem, which permits (potentially computationally intensive) global solutions as well as approximate solutions using heuristics based on convex optimization.

Outline.

We describe the optimal routing problem in §1, ignoring the fixed transaction costs. In §2 we give the optimality conditions for the optimal routing problem, and give conditions under which the optimal action is to not trade at all. We give some examples of the optimal routing problem in §3, including as a special case the detection of arbitrage in the network. We give a simple numerical example in §4. In §5 we show how to add fixed transaction costs to the optimal routing problem, and briefly describe some exact and approximate solution approaches.

1. Optimal routing problem

Network of CFMMs.

We consider a set of m CFMMs, denoted i=1, \ldots, m, each of which trades multiple tokens from among a universe of n tokens, labeled j=1 \ldots, n. We let n_i denote the number of tokens that CFMM i trades, with 2 \leq n_i \leq n. We can think of the m CFMMs as the vertices of a network or hypergraph, with n hyper-edges, each corresponding to one of the n assets, adjacent to those CFMMs that trade it. Alternatively we can represent this as a bipartite graph, with one group of m vertices the CFMMs, and the other group of n vertices the tokens, with an edge between a CFMM and a token if the CFMM trades the token.

A simple example is illustrated as a bipartite graph in figure 1. In this network there are m=5 CFMMs, which trade subsets of n=3 tokens. CFMM 1 trades all three tokens, so n_1=3; the remaining 4 CFMMs each trade pairs of tokens, so n_2= \cdots = n_5=2.

Figure 1: Example CFMM network with m=5 CFMMs and n=3 tokens.

Global and local token indices.

We use multiple indices to label the tokens. The global index uses the token labels 1, \ldots, n. CFMM i, which trades a subset of n_i of the n tokens, has its local token index, j=1, \ldots, n_i. To link the global and local indexes, we introduce matrices A_i \in {{\bf R}}^{n \times n_i}, i=1\ldots, m, where (A_i)_{jk} = 1 if token k in the CFMM i‘s local index corresponds to global token index j, while (A_i)_{jk} =0 otherwise.

As an example, consider the simple network shown in figure 1. CFMM 1 trades all four tokens, with its local indexing identical to the global indexing, so A_1 is the 3\times 3 identity matrix. As a more interesting example, consider CFMM 4, which trades two tokens, labeled 1 and 2 in the local indexing, but 1 and 3 in the global indexing, so A_4 = \begin{bmatrix} 1 & 0\\ 0 & 0\\ 0 & 1\\ \end{bmatrix}.

CFMM tendered and received baskets.

For CFMM i we denote the tendered and received baskets as \Delta_i,~\Lambda_i \in {{\bf R}}_+^{n_i}. These are quantities of tokens (in the local indexing) that we give to, and receive from, CFMM i in a proposed trade.

CFMM trading semantics.

The proposed trade (\Delta_i,\Lambda_i) is valid and accepted by CFMM i provided \varphi_i(R_i+\gamma \Delta_i - \Lambda_i) = \varphi_i(R_i), where \varphi: {{\bf R}}^{n_i}_+ \to {{\bf R}} is the trading function, R_i \in {{\bf R}}_+^{n_i} are the current reserves, and \gamma_i \in (0,1] is the trading fee for CFMM i. We will assume that the trading functions \varphi_i are concave and increasing functions. (For much more detail, see5.)

Examples of trading functions are the sum function, with \varphi_i(R)= R_1+ \cdots + R_{n_i}, the product or geometric mean function \varphi_i(R)= (R_1 \cdots R_{n_i})^{1/n_i}, and a generalization, the weighted geometric mean function \varphi_i(R)= R_1^{w_1} \cdots R_{n_i}^{w_{n_i}}, with weights w>0, \mathbf 1^Tw=1, where \mathbf 1 is the vector with all components one.

Network trade vector.

The CFMM tendered and received baskets \Delta_i and \Lambda_i can be mapped to the global indices as the n-vectors A_i \Delta_i and A_i \Lambda_i, which give the numbers of tokens tendered to and received from CFMM i, using the global indices for the tokens. Summing the difference of received and tendered tokens over all CFMMs we obtain the network trade vector \Psi = \sum_{i=1}^m A_i (\Lambda_i - \Delta_i). This is an n-vector, which gives the total net number of tokens tendered to the CFMMs in the network. We interpret \Psi as the net network trade vector. If \Psi_k \geq 0, it means that we do not need to tender any of token k to the network. This does not mean we that do not trade token k; it only means that in our trading with the CFMMs, we receive at least as much as token k as we tender.

Network trade utility.

We introduce a utility function U:{{\bf R}}^n \to {{\bf R}}\cup \{-\infty\} that gives the utility of a trade \Psi to a trader as U(\Psi). We will assume that U is concave and increasing. Infinite values of U are used to impose constraints; we consider a proposed trade with U(\Psi) = -\infty as unacceptable. As an important example, consider the constraint \Psi + h \geq 0, where h \in {{\bf R}}_+^n is the vector of a user’s current holdings of tokens. This constraint specifies that the post-trade holdings \Psi+ h should be nonnegative, i.e., we cannot enter into a trade that requires more of any token than we currently have on hand. To express this in the utility function, we define U(z) to be -\infty when z+g \not\geq 0. (This modified utility is also concave and increasing.)

There are many possible choices for U. Perhaps the simplest is the linear utility function U(z) = \pi^Tz, with \pi \in {{\bf R}}_{++}, where we interpret \pi_i as the trader’s internal or private value or price of token i. Several other choices are discussed in8.

Optimal routing problem.

We wish to find a set of valid trades that maximizes the trader’s utility. This optimal routing problem can be expressed as

(1)\begin{aligned} & \text{maximize} && U(\Psi)\\ & \text{subject to} && {\textstyle \Psi = \sum_{i=1}^m A_i(\Lambda_i - \Delta_i)}\\ &&& \varphi_i(R_i + \gamma_i \Delta_i - \Lambda_i) = \varphi_i(R_i), \quad i=1, \dots, m\\ &&& \Delta_i \geq 0, \quad \Lambda_i \geq 0, \quad i=1, \ldots, m. \end{aligned}

The variables here are \Psi \in {{\bf R}}^n, \Lambda_i \in {{\bf R}}_+^{n_i}, \Delta_i \in {{\bf R}}^{n_i}_+, i=1, \ldots, m. The data are the utility function U, the global-local matrices A_i, and those associated with the CFMMs, the trading functions \varphi_i, the trading fees \gamma_i, and the reserve amounts R_i \in {{\bf R}}^{n_i}_+.

Convex optimal routing problem.

Unless the trading functions are affine, the optimal routing problem (1) is not a convex optimization problem. We can, however, form an equivalent problem that is convex. To do this we replace the equality constraints with inequality constraints:

(2)\begin{aligned} & \text{maximize} && U(\Psi)\\ & \text{subject to} && {\textstyle \Psi =\sum_{i=1}^m A_i(\Lambda_i-\Delta_i)}\\ &&& \varphi_i(R_i + \gamma_i \Delta_i - \Lambda_i) \ge \varphi_i(R_i), \quad i=1, \dots, m\\ &&& \Delta_i \geq 0, \quad \Lambda_i \geq 0, \quad i=1, \ldots, m. \end{aligned}

This problem is evidently convex9 and can be readily solved.

We will show that any solution of (2) is also a solution of (1). This the same as showing that for any solution of (2), the inequality constraints hold with equality. Suppose that \Delta_i^\star and \Lambda_i^\star are feasible for (2), but \varphi_k(R_k + \gamma_k \Delta^\star_k - \Lambda^\star_k) > \varphi_k(R_k) for some k. This means we can find \tilde \Lambda > \Lambda^\star_k which satisfies \varphi_k(R_k + \gamma_k \Delta^\star_k - \tilde \Lambda) \geq \varphi_k(R_k). The associated trade vector \tilde \Psi = \Psi^\star + A_k \Lambda_k satisfies \tilde \Psi \geq \Psi^\star, \tilde \Psi \neq \Psi^\star, i.e., at least one component of \tilde \Psi is larger that the corresponding component of \Psi^\star. It follows that U(\tilde \Psi) > U(\Psi^\star), so \Psi^\star is not optimal and therefore cannot be a solution. We conclude that any solution of (2) satisfies the inequality constraints as equality, and so is optimal for (1).

A similar statement holds in the case when U is only nondecreasing, and not (strictly) increasing. In this case we can say that there is a solution of (2) that is optimal for (1). One simple method to find such a solution is to solve (2) with objective U(\Psi)+\epsilon \mathbf 1^T\Psi, where \epsilon is small and positive. The objective for this problem is increasing. In principle we can let \epsilon go to zero to recover a solution of the original problem; in practice choosing a single small value of \epsilon works.

Consequences of convexity.

Since the problem (2) is convex, it can be reliably and quickly solved, even for large problem instances10. Domain specific languages for convex optimiztion such as CVXPY1112 or JuMP13 can be used to specify the optimal routing problem in just a few lines of code; solvers such as ECOS14, SCS15, or Mosek16 can be used to solve the problem.

Implementation.

The solution to (2) provides the optimal values (\Delta_i,\Lambda_i) that one must trade with each CFMM i. Note that we do not explicitly consider the ideal execution of these trades, as these will depend on the semantics of the underlying blockchain that the user is interacting with. For example, users may wish to execute trades in a particular sequence, starting with an initial portfolio of assets and updating their asset composition after each transaction until the final basket is obtained. Users may alternatively use flashloans17 to atomically perform all trades in a single transaction, netting out all trades before repaying the loan at the end of the transaction.

2. Optimality conditions

Assuming that U is differentiable (which it need not be), the optimality conditions of problem (2) are feasibility, and the dual conditions

(3)\nabla U(\Psi) = \nu,

and

(4)\gamma_i\lambda_i \nabla\varphi_i(R_i + \gamma_i\Delta_i - \Lambda_i) \le A_i^T\nu \le \lambda_i\nabla\varphi_i(R_i + \gamma_i \Delta_i - \Lambda_i), \quad i=1, \ldots, m,

where \nu \in {{\bf R}}^n, \lambda_i \in {{\bf R}}_+, i=1,\ldots, m are the Lagrange multipliers. (We derive these conditions in appendix A.)

The first condition (3) has a very simple interpretation: \nu is the vector of marginal utilities of the tokens. The second set of conditions (4) has a simple interpretation that is very similar to the one given in18 for a single CFMM. The term \nabla \varphi_i(R_i + \gamma_i\Delta_i - \Lambda_i), which we will write as P_i \in {{\bf R}}^{n_i}_+, can be interpreted as the unscaled prices of the tokens that CFMM i trades19, in the local indexing. Plugging (3) into (4),we get

(5)\gamma_i\lambda_iP_i \le A_i^T\nabla U(\Psi) \le \lambda_iP_i, \quad i=1, \dots, m.

The middle term is the vector of marginal utilities of the tokens that CFMM i trades, in the local indexing. These marginal utilities must lie between a multiple of the discounted prices, scaled, and the same prices, adjusted by \gamma_i.

We can also recognize the conditions (4) as those for the problem of finding an optimal trade for CFMM i alone, with the linear utility U_i(z) = \pi_i^T z, where \pi_i = A_i^T \nabla U(\Psi). (See8.) This is very appealing: it states that the optimal trades for the network of CFMMs are also optimal for each CFMM separately, when they use a linear utility, with prices equal to the marginal utility of the overall trade.

Non-differentiable utility.

When U is not differentiable, the optimality conditions are the same, but in (3) we substitute a supergradient g \in -\partial (-U)(\Psi) for the gradient \nabla U(\Psi), where \partial denotes the subdifferential. When U is not differentiable at \Psi, there are multiple such g‘s, which we can consider to be multiple marginal utilities. The optimality condition is that (5) hold, with \nabla U(\Psi) replaced with g, for any g \in -\partial (-U)(\Psi).

No-trade condition.

From the optimality conditions we can derive conditions under which the optimal trades are zero, i.e., we should not trade. We will assume that U(0) > -\infty, i.e., \Psi=0 is feasible; if this is not the case, then evidently \Psi=0 is not optimal. The zero trade \Psi=0, \qquad \Delta_i = \Lambda_i = 0, \quad i=1, \ldots, m, is feasible for (5), so the optimality condition is

(6)\gamma_i\lambda_i P_i \le A_i^T\nabla U(0) \le \lambda_iP_i, \quad i=1, \ldots, m,

where P_i = \nabla \varphi_i(R_i) is the unscaled price of CFMM i at the current reserves R_i. This condition is a generalization of the no-trade condition given in18 for one CFMM, to the case where there are multiple CFMMs. When U is not differentiable, we replace \nabla U(0) with a supergradient g \in -\partial (-U)(0).

3. Examples

Linear utility.

Consider the linear utility U(z)=\pi^Tz, with \pi >0. In this case the optimal routing problem is separable across the CFMMs, since the objective is a sum of functions of \Lambda_i-\Delta_i, and constraints are also only on (\Lambda_i,\Delta_i). It follows that we can solve the optimal routing problem (2) by solving m single CFMM problems independently, using linear utilities with prices given by \pi.

Liquidating a basket of tokens.

Suppose we start with an initial holding (basket) of tokens h^\text{init} \in {{\bf R}}_+^n and wish to convert them all to token k. We use the utility function U(z) = \left\{ \begin{array}{ll} z_k & h^\text{init} + z \geq 0\\ -\infty & {otherwise.} \end{array}\right. (This utility is nondecreasing but not increasing.)

A special case of this problem is converting one token into another, i.e., when h^\mathrm{init} = t e_j, where t \ge 0 and e_j \in {{\bf R}}^n is the jth unit vector. In this special case, we can write the optimal value of the optimization problem, which we will call u(t), as a function of t. It is not hard to show that u is nonnegative and increasing. This function is also concave as it is the partial maximization of a concave function (over all variables except t). We show an example instance of this problem, along with an associated function u, in §3.

Purchasing a basket of tokens.

This is the opposite of liquidating a basket of tokens. Here too we start with initial token holdings h^\text{init} \in {{\bf R}}_+^n, and end up with the holdings h^\text{init} + \Psi. Let h^\text{des} \in {{\bf R}}_+^n be our target basket; we wish to end up with the largest possible multiple of this basket. Let \mathcal K \subseteq \{1, \ldots, n\} denote the set of indices for which h^\text{des}_i>0, i.e., the indexes associated with tokens in the desired basket. We seek to maximize the value of \alpha for which h^\text{init} + \psi \geq \alpha h^\text{des}. To do this we use the utility function U(z) = \left\{ \begin{array}{ll} \min_{i \in \mathcal K} (h_i^\text{init}+\Psi_i)/ h_i^\text{des} & h^\text{init} + z \geq 0\\ -\infty & {otherwise.} \end{array}\right.

Arbitrage detection.

An arbitrage is a collection of valid CFMM trades with \Psi \geq 0 and \Psi \neq 0, i.e., a set of trades for the CFMMs in which we tender no tokens, but receive a positive amount of at least one token. The optimal routing problem can be used to find an arbitrage, or certify that no arbitrage exists.

Consider any U that is increasing, with domain \{\Psi \mid U(\Psi)>-\infty \} = {{\bf R}}_+^n. Evidently there is an arbitrage if and only if there is a nonzero solution of the routing problem, which is the same as U(\Psi^\star) > U(0), where \Psi^\star is optimal. So by solving this optimal routing problem, we can find an arbitrage, if one exists.

No-arbitrage condition.

Using the version of (6) for nondifferentiable U we can derive conditions under which there is no arbitrage. We consider the specific utility function U(\Psi) = \left\{ \begin{array}{ll} \mathbf 1^T \Psi & \Psi \geq 0\\ -\infty & {otherwise}, \end{array}\right. where \mathbf 1 denotes the vector with all entries one. This utility is the total number of tokens received, when they are nonnegative. Its supergradient at 0 is -\partial (-U)(0) = [1,\infty)^n = \{ g\mid g \geq \mathbf 1\}. The condition (6) becomes: There exists g \geq \mathbf 1, and \lambda_i \geq 0, for which \gamma_i\lambda_i P_i \le A_i^T g \le \lambda_iP_i, \quad i=1, \ldots, m. By absorbing a scaling of g into the \lambda_i, we can say that g>0 is enough.

This makes sense: it states that there is no arbitrage if we can assign a set of positive prices (given by g) to the tokens, for which no CFMM would trade. In the (unrealistic) case when \gamma_i=1, i.e., there is no trading cost, the no arbitrage condition is that there exists a global set of prices for the tokens, g, consistent with the local prices of tokens given by \lambda_iP_i.

4. Numerical example

The Python code for the numerical example we present here is available at

https://github.com/angeris/cfmm-routing-code

The optimization problems are formulated and solved using CVXPY12. A listing of the core of the code is given in appendix B.

Table 1: CFMM attributes.

Network.

We consider the network of 5 CFMMs and 3 tokens shown in figure 1. The trading functions, Fee parameters, and reserves are listed in table 1.

Problem and utility.

We wish to trade an amount t\geq 0 of token 1 for the maximum possible amount of token 3. This is a special case of the problem of liquidating a basket of tokens, as described in §3, with initial holdings h^\text{init}=t e_1. The utility function is U(z) = z_3, provided z+h^\text{init} \geq 0, and U(z) = -\infty otherwise. We let u(t) denote the maximum amount of token 3 we can obtain from the network when we tender token 1 in the amount t.

Results.

We solve the optimal routing problem for many values of t, from t=0 to t=50. The amount of token 3 we obtain in shown in figure 2l. We see that u(0) > 0, which means there is an arbitrage in this network; indeed, there is a set of trades that requires giving zero net tokens to the network, but we receive an amount around 7 of token 3.

The associated optimal trades are shown in figure 3. We can see many interesting phenomena here. At t=0 we see the arbitrage trades, indeed, the arbitrage trades that yield the largest amount of token 3. Several asset flows reverse sign as t varies. For example, for t<11, we receive token 1 from CFMM 1, whereas for t>11, we tender token 1 to CFMM 1. We can also see that the sparsity pattern of the optimal trades changes with t.

We illustrate the changing signs and sparsity of the optimal trades in figure 4, which shows the optimal trades for t=0, t=20, and t=50. We plot whether each token is tendered to or received from each CFMM using color coded edges. A red edge connecting a token to a CFMM means that the CFMM is receiving this token, while a blue edge denotes that the CFMM is tendering this token. A dashed edge denotes that the CFMM neither tenders nor receives this token.

Even in this very simple example, the optimal trades are not obvious and involve trading with and among multiple CFMMs. For larger networks, the optimal trades are even less obvious.

Figure 2: Plot of u(t), the maximum amount of token 3 we obtain when we tender the amount t of token 1.

Figure 3: Optimal trades versus t, the amount of token 1 tendered.

Figure 4: Optimal trades as t varies. A red edge means the CFMM is receiving tokens; a blue edge means the CFMM is tendering tokens.

5. Fixed transaction costs

Our optimal routing problem (2) includes the trading costs built into CFMMs, via the parameters \gamma_i. But it does not include the small fixed cost associated with any trade. In this section we explore how these fixed transaction costs can be incorporated into the optimal routing problem.

We let q_i \in {{\bf R}}_+ denote the fixed cost of executing a trade with CFMM i, denominated in some numeraire. We pay this whenever we trade, i.e., \Lambda_i - \Delta_i \neq 0. We introduce a new set of Boolean variables into the problem, \eta \in \{0, 1\}^m, with \eta_i = 1 if a nonzero trade is made with CFMM i, and \eta_i = 0 otherwise, so the total fixed transaction cost is q^T\eta. We assume that there is a known maximum size of a tendered basket with CFMM i, which we will denote \Delta^\mathrm{max}_i \in {{\bf R}}_+^{n_i}. We can then express the problem of maximizing the utility minus the fixed transaction cost as

(7)\begin{aligned} & \text{maximize} && U(\Psi) - q^T\eta\\ & \text{subject to} && {\textstyle \Psi =\sum_{i=1}^m A_i(\Lambda_i - \Delta_i)}\\ &&& \varphi_i(R_i + \gamma_i \Delta_i - \Lambda_i) \ge \varphi_i(R_i), \quad i=1, \dots, m\\ &&& 0 \le \Delta_i \le \eta_i\Delta^\mathrm{max}_i, \quad \Lambda_i \ge 0, \quad i=1, \dots, m,\\ &&& \eta \in\{0, 1\}^m, \end{aligned}

where the variables are \Psi, \Lambda_i, \Delta_i, i=1, \ldots, m, and \eta \in \{0,1\}^m.

The optimal routing problem with fixed costs (7) is a mixed-integer convex program (MICP). It can be solved exactly, possibly with great computational effort, using global optimization methods, with MICP solvers such as Mosek16 or Gurobi20. When m is small (say, under ten or so), it can be practical to solve it by brute force, by solving the convex problem we obtain for each of the 2^m feasible values of \eta.

Approximate solution methods.

Many approximate methods have the speed of convex optimization, and (often) produce good approximate solutions. For example we can solve the relaxation of (7) obtained by replacing the constraints on \eta to \eta \in[0,1]^m (which gives a convex optimization problem). After that we set a threshold t\in (0,1) for the relaxed optimal values \eta^\text{rel}, and take \eta_i = 1 when \eta^\text{rel}\geq t and and \eta_i = 0 when \eta^\text{rel}<t. We fix these values of \eta and then solve the resulting convex problem. This could be done for a modest number of values of t; we take the solution found with the largest objective (including the fixed costs q^T\eta).

An alternative is a simple randomized method. We interpret \eta^\text{rel}_i as probabilities, and generate \eta \in \{0,1\} randomly using these probabilities. Then we solve the convex problem associated with this choice of \eta. We repeat this a modest number of times.

Appendix A: Derivation of optimality conditions

To derive condition (4), we introduce the Lagrangian of the convex optimal routing problem (2), \mathcal{L}(\Psi, \Delta, \Lambda, \nu, \lambda, \eta, \xi) = -U(\Psi) + \nu^T\left(\Psi - \sum_{i=1}^m A_i(\Lambda_i - \Delta_i)\right) \\ + \sum_{i=1}^m \lambda_i(\varphi_i(R_i) - \varphi_i(R_i+\gamma_i\Delta_i - \Lambda_i)) - \sum_{i=1}^m (\eta_i^T\Delta_i + \xi_i^T\Lambda_i).

Here, \nu \in {{\bf R}}^n, \lambda \in {{\bf R}}^m_+, and \eta_i, \xi_i \in {{\bf R}}^{n_i}_+, i=1, \dots, m. These are the dual variables or Lagrange multipliers for the equality constraint, the relaxed inequality constraints, and nonnegativity constraints for the tendered and received baskets of assets for each CFMM, respectively.

The optimality conditions are (primal) feasibility, and (the dual conditions) \nabla_\Psi \mathcal{L} = 0, \quad \nabla_\Delta\mathcal{L}=0, \quad \nabla_\Lambda\mathcal{L} = 0. The first of these is -\nabla U(\Psi) + \nu = 0, while the latter two are -A_i^T\nu + \lambda_i\nabla\varphi_i(R_i+\gamma_i\Delta_i - \Lambda_i) - \xi_i = 0, \qquad A_i^T\nu - \gamma_i\lambda_i\nabla\varphi_i (R_i+\gamma_i\Delta_i - \Lambda_i) - \eta_i = 0. These can be written as -A_i^T\nu + \lambda_i\nabla\varphi_i(R_i+\gamma_i\Delta_i - \Lambda_i) \ge 0, \qquad A_i^T\nu - \gamma_i\lambda_i\nabla\varphi_i(R_i+\gamma_i\Delta_i - \Lambda_i) \ge 0, which simplifies to (4).

Appendix B: Example Code

import numpy as np
import cxvpy as cp

# We assume the following is already defined:
# - 'A', list of matrices A_i
# - 'reserves', list of vectors R_i
# - 'fees', list of fees for each CFMM i
# - 'num_tokens', list of n_i
# - 't', amount of asset 1 provided to the network

current_assets = np.array([t, 0, 0])

# Build variables
deltas = [cp.Variable(n_i, nonneg=True) for n_i in num_tokens]
lambdas = [cp.Variable(n_i, nonneg=True) for n_i in num_tokens]
psi = cp.sum(A_i @(L - D) for A_i, D, L in zip(A, deltas, lambdas))

# Objective is to trade t of asset 1 for a maximum amount of asset 3
obj = cp.Maximize(psi[2])

# Reserves after trade
new_reserves = [R + gamma_i *D - L \
for R, gamma_i, D, L in zip(reserves, fees, deltas, lambdas)]

# Trading function constraints
cons =[
    # Balancer pool with weights 3, 2, 1
    cp.geo_mean(new_reserves[0], p=np.array([3, 2, 1])) \
    >= cp.geo_mean(reserves[0], p=np.array([3, 2, 1])),
    # Uniswap v2 pools
    cp.geo_mean(new_reserves[1]) >= cp.geo_mean(reserves[1]),
    cp.geo_mean(new_reserves[2]) >= cp.geo_mean(reserves[2]),
    cp.geo_mean(new_reserves[3]) >= cp.geo_mean(reserves[3]),
    # Constant sum pool
    cp.sum(new_reserves[4]) >= cp.sum(reserves[4]),
    new_reserves[4] >= 0,
    # Allow all assets at hand to be traded
    psi + current_assets >= 0
]

# Set up and solve problem
prob = cp.Problem(obj, cons)
prob.solve()

print(f" amount of asset 3 received: {psi[2].value}")
  1. Guillermo Angeris and Tarun Chitra. Improved Price Oracles: Constant Function Market Makers. In Proceedings of the 2nd ACM Conference on Advances in Financial Technologies, pages 80–91, New York NY USA, October 2020. ACM. [↩] [↩]
  2. Yi Zhang, Xiaohong Chen, and Daejun Park. Formal specification of constant product (xy = k) market maker model and implementation. 2018. [↩]
  3. Dex aggregator volume. https://www.theblockcrypto.com/data/decentralizedfinance/dex-non-custodial/dex-aggregator-trade-volume, 2021. [↩]
  4. Uniswap Labs. Uniswap Router02. 2021. 13 [↩]
  5. Guillermo Angeris, Akshay Agrawal, Alex Evans, Tarun Chitra, and Stephen Boyd. Constant Function Market Makers: Multi-Asset Trades via Convex Optimization. arXiv:2107.12484 [math, q-fin], July 2021. [↩] [↩]
  6. Vincent Danos, Hamza El Khalloufi, and Julien Prat. Global order routing on exchange networks. In International Conference on Financial Cryptography and Data Security, pages 207–226. Springer, 2021. [↩]
  7. Daniel Engel and Maurice Herlihy. Composing networks of automated market makers. CoRR, abs/2106.00083, 2021. [↩]
  8. Guillermo Angeris, Akshay Agrawal, Alex Evans, Tarun Chitra, and Stephen Boyd. Constant Function Market Makers: Multi-Asset Trades via Convex Optimization. arXiv:2107.12484 [math, q-fin], July 2021. §5.2 [↩] [↩]
  9. Stephen Boyd and Lieven Vandenberghe. Convex Optimization. Cambridge University Press, Cambridge, UK ; New York, 2004. §5.2.1 [↩]
  10. Stephen Boyd and Lieven Vandenberghe. Convex Optimization. Cambridge University Press, Cambridge, UK ; New York, 2004. §1 [↩]
  11. Steven Diamond and Stephen Boyd. Cvxpy: A python-embedded modeling language for convex optimization. The Journal of Machine Learning Research, 17(1):2909–2913, 2016. [↩]
  12. Akshay Agrawal, Robin Verschueren, Steven Diamond, and Stephen Boyd. A rewriting system for convex optimization problems. Journal of Control and Decision, 5(1):42–60, 2018. [↩] [↩]
  13. Iain Dunning, Joey Huchette, and Miles Lubin. JuMP: A modeling language for mathematical optimization. SIAM Review, 59(2):295–320, January 2017. [↩]
  14. Alexander Domahidi, Eric Chu, and Stephen Boyd. ECOS: An SOCP solver for embedded systems. In 2013 European Control Conference (ECC), pages 3071– 3076, Zurich, July 2013. IEEE. [↩]
  15. Brendan O’Donoghue, Eric Chu, Neal Parikh, and Stephen Boyd. Conic optimization via operator splitting and homogeneous self-dual embedding. Journal of Optimization Theory and Applications, 169(3):1042–1068, June 2016. [↩]
  16. MOSEK ApS. MOSEK Optimizer API for Python 9.1.5. https://docs.mosek.com/9.1/pythonapi/index.html, 2019. [↩] [↩]
  17. Aave. Flash loans: Pushing the limits of DeFi. https://aave.com/flash-loans/, 2020. [↩]
  18. Guillermo Angeris, Akshay Agrawal, Alex Evans, Tarun Chitra, and Stephen Boyd. Constant Function Market Makers: Multi-Asset Trades via Convex Optimization. arXiv:2107.12484 [math, q-fin], July 2021. §5.1 [↩] [↩]
  19. Guillermo Angeris, Akshay Agrawal, Alex Evans, Tarun Chitra, and Stephen Boyd. Constant Function Market Makers: Multi-Asset Trades via Convex Optimization. arXiv:2107.12484 [math, q-fin], July 2021. §2.5 [↩]
  20. Gurobi Optimization, LLC. Gurobi Optimizer Reference Manual, 2021. [↩]
Share
  • Download PDF
  • Share on Twitter
  • Copy Link
Contents
  • Abstract
  • Introduction
  • 1. Optimal routing problem
  • 2. Optimality conditions
  • 3. Examples
  • 4. Numerical example
  • 5. Fixed transaction costs
  • Appendix A: Derivation of optimality conditions
  • Appendix B: Example Code
BainCapital
  • Twitter
  • LinkedIn
  • Terms of Use
  • Disclosures