Introduction

In Decentralized Finance (DeFi) systems, Automated Market Makers (AMMs) are decentralized exchanges (DEXs) that provide users with liquidity using different reserves, enabling them to trade different crypto-assets, i.e., tokens. Users participating in these token exchanges pay fixed trading and gas fees charged by the Ethereum network. Similarly to traditional financial systems, users need to provide an upfront amount of crypto-assets as collateral to operate with such decentralized financial services. Liquidity is essential for AMMs to work properly, otherwise, it is possible to incur scenarios that hinder their economic performance and limit user involvement.

AMMs rely on users who act as liquidity providers by depositing a certain amount of tokens into AMM smart contracts that can be used for trades. AMM protocols implement liquidity-saving mechanisms (LSM) that aim at reducing liquidity costs by minimizing the required liquidity for transaction settlement. DeFi protocols have introduced various approaches to achieve this goal, e.g., flash loans [1,2] and flash swaps [3]. These mechanisms allow users to temporarily loan tokens with no collateral but require them to pay back their debt within a single transaction. One of their limitations is that they do not easily permit scenarios with more users involved or trades requiring more than one transaction to be completed.

In this paper, we propose the design of an LSM for AMMs that offers the advantages of flash loans and flash swaps but overcomes their limitations. In particular, our mechanism permits users to operate on the AMM without upfront balance by aggregating multiple actions over a specific time frame. Our aggregation mechanism is inspired by netting [4,5,6], an LSM used in traditional finance: netting creates payment instruction queues among banks, offsets the value of multiple payments, and finds the most convenient payment combination to eliminate stunting periods. We provide here a formalization of our mechanism in terms of a labelled transition system (LTS) that precisely characterizes the interactions between users and AMMs and the conditions when the netting mechanism is triggered.

Intuitively, our mechanism works as follows. First, we equip AMMs with a finite queue to store trading transactions (swaps) proposed by users. When a user performs a transaction that would result in a balance overdraft, the transaction is stored in the queue. Otherwise, if the transaction has the effect of setting all balances of users having pending transactions in the queue to positive, the transaction queue is executed atomically, resulting in a liquidity-saving sequence of swaps. If the queue reaches its maximum capacity where some users' balances are still negative, a netting algorithm selects a subset of the stored transactions that meet the liquidity constraints for each user, if any, and atomically performs them. In such a way, users capitalize on market inefficiencies, facilitating the trading of assets more efficiently and cost-effectively. We discuss the scenarios where our proposed netting-based AMM and traditional AMM differ in the performed swap transactions. In particular, we show examples of multi-party trading operations that are not executed in standard AMMs due to lack of liquidity but are settled by ours.

In summary, our main contributions are:

• We provide an LSM that settles AMM trades through a netting algorithm and allows us to implement liquidity-optimized AMM. We illustrate examples that allow users to perform multiparty exchanges and multi-AMM arbitrage without the upfront liquidity that would be required in traditional AMMs. • We formalize our mechanism by adopting the operational semantics of the interactions between users and AMMs proposed by Bartoletti et al. [7]. We adapt their semantics by removing the liquidity constraints on users' balances when performing swap actions and by appending swap transactions in a queue until a liquidity-balanced state is reached. • We provide a lightweight netting algorithm that can run on the blockchain as part of a smart contract to select a subset of swaps that can actually be performed without violating any liquidity constraints.

In the rest of the paper we proceed as follows. We provide a high-level overview of our approach in Section 2. Section 3 presents the operational semantics of our LSM mechanism, together with relevant scenarios comparing it with standard AMMs. Section 4 discusses related literature, and Section 5 concludes and discusses some future work.

Overview of the approach

In current DeFi protocols, such as Uniswap [3], a user interacts with the AMM reserve through single actions. She can deposit, redeem, or swap crypto-assets in change of others in the AMM. However, she can perform the transaction only if she has the needed capital upfront to cover it. For instance, consider the example of Figure 1 where there are two users A and B that interact with two AMMs performing a sequence of swap actions 𝑠 1 𝑠 2 𝑠 3 𝑠 4 . Initially, user A owns 4 tokens of type 𝜏 2 , no tokens of types 𝜏 0 and 𝜏 1 (denoted with the notation A[0 : 𝜏 0 , 0 : 𝜏 1 , 4 : 𝜏 2 ] in the figure); whereas user B has 4 tokens of type 𝜏 0 , no tokens of types 𝜏 1 and 𝜏 2 . The AMMs have 12 tokens type of 𝜏 0 , 𝜏 1 and 𝜏 1 , 𝜏 2 , respectively (denoted with {12 : 𝜏 0 , 12 : 𝜏 1 } and {12 : 𝜏 1 , 12 : 𝜏 2 } in the figure). The main idea is that the sequence of transactions would allow A and B to exchange their tokens at 1-to-1 rate, via the two AMMs. In standard protocols, some transactions are rejected because users' balances cannot cover their fulfillment: A cannot perform 𝑠 1 , namely swapping 6 tokens for at least 4 tokens of type 𝜏 0 , in symbols 𝑠 1 = A : swap(6 : 𝜏 1 , 4 : 𝜏 0 ), and B cannot perform 𝑠 2 , in symbols 𝑠 2 = B : swap(6 : 𝜏 1 , 4 : 𝜏 2 ). Our LSM overcomes the previous scenario. It allows users to instantaneously perform transactions whenever they lead to a state where the overall balance is positive. Otherwise, these transactions are delayed and stored in a queue. Once the queue is full, the protocol executes a netting procedure to discard the transactions that make balances negative. Thus, the protocol reaches a state where no liquidity constraints are violated, and transactions can be safely performed. The underlying idea of our mechanism is to accept a momentary deficit in users' balances as long as they may be covered by subsequent transactions, for instance, a swap in a different direction made by the same user or an update to the token reserve. Back to the example of Figure 1, our approach allows the sequence of the actions 𝑠 1 𝑠 2 𝑠 3 𝑠 4 (for each action in the figure, we report how it affects the user balances and AMM reserves) to be executed since the 𝑠 4 yields a state where all balances are positive. It is not relevant if there are intermediate states where user balances are temporarily negative (colored in the figure). In this way, our LSM permits a multi-party trade between A and B, even when they do not have sufficient funds. In contrast, traditional AMMs reject all four swap actions due to lack of liquidity.

User A [0 : 𝜏 0 , 0 : 𝜏 1 , 4 : 𝜏 2 ] AMM 1 {12 : 𝜏 0 , 12 : 𝜏 1 } AMM 2 {12 : 𝜏 1 , 12 : 𝜏 2 } User B [4 : 𝜏 0 , 0 : 𝜏 1 , 0 : 𝜏 2 ] 𝑠 1 = A : swap(6 : 𝜏 1 , 4 : 𝜏 0 ) A[4 : 𝜏 0 , −6 : 𝜏 1 , 4 : 𝜏 2 ]|𝐴𝑀 𝑀 1 {8 : 𝜏 0 , 18 : 𝜏 1 } 𝑠 2 = B : swap(6 : 𝜏 1 , 4 : 𝜏 2 ) B[4 : 𝜏 0 , −6 : 𝜏 1 , 4 : 𝜏 2 ]|𝐴𝑀 𝑀 2 {18 : 𝜏 1 , 8 : 𝜏 2 } 𝑠 3 = A : swap(4 : 𝜏 2 , 6 : 𝜏 1 ) A[4 : 𝜏 0 , 0 : 𝜏 1 , 0 : 𝜏 2 ]|𝐴𝑀 𝑀 2 {12 : 𝜏 1 , 12 : 𝜏 2 } 𝑠 4 = B : swap(4 : 𝜏 0 , 6 : 𝜏 1 ) B[0 : 𝜏 0 , 0 : 𝜏 1 , 4 : 𝜏 2 ]|𝐴𝑀 𝑀 1 {12 : 𝜏 0 , 12 : 𝜏 1 }

Liquidity-saving mechanism

This section formalizes our LSM, illustrates our netting algorithm, and shows how our approach differs from the standard one through some examples.

Formal model of Automated Market Makers

We formalize the interaction between users and AMMs as a labelled transition system (LTS). Our semantics is based on those of Bartoletti et al. [7]. Intuitively, LTS states represent the system configurations that store each user's token supplies and the AMMs. Transitions represent transactions performed by users, which may result in an update of token supplies. For the time being, we focus only on swap actions and neglect redeem and deposit. We also assume that swap actions require no fees and that there are no transaction fees.

AMM basic definitions

We assume a set T of atomic token types (ranged over by 𝜏, 𝜏 ′ ) representing native cryptocurrencies and application-specific tokens. In general, we denote with 𝑟, 𝑟 ′ real numbers (R), and we write 𝑟 : 𝜏 to denote 𝑟 atomic tokens of type 𝜏 (𝜏 ∈ T).

We also assume a set of users A (ranged over by A, A ′ ). The wallet of a user A is denoted by A[𝜎 A ], where the partial map 𝜎 A ∈ T ⇀ R represents A token balances, i.e., 𝜎 A (𝜏 ) denotes the amount of 𝜏 owned by A.

We model the AMM as a reserve of 𝑟 0 : 𝜏 0 and 𝑟 1 : 𝜏 1 where 𝜏 0 ̸ = 𝜏 1 , written as an unordered pair {𝑟 0 : 𝜏 0 , 𝑟 1 : 𝜏 1 }.

The states Γ, Γ ′ of the protocol are finite non-empty compositions of wallets and AMM. Formally, they are defined as follows:

Γ = [A 1 [𝜎 A 1 ]| • • • | A 𝑛 [𝜎 A𝑛 ] | {𝑟 0 : 𝜏 0 , 𝑟 1 : 𝜏 1 } | • • • | {𝑟 𝑤 : 𝜏 𝑤 , 𝑟 𝑘 : 𝜏 𝑘 }](1)

and for the sake of simplicity of our formalization, we assume the following conditions: for all 𝑖 ̸ = 𝑗 (𝑖) each user has a single wallet (A 𝑖 ̸ = A 𝑗 ); (𝑖𝑖) distinct AMMs cannot hold exactly the same token types ({𝜏 𝑖 , 𝜏 ′ 𝑖 } ̸ = {𝜏 𝑗 , 𝜏 ′ 𝑗 }). The labels of LTS are swap transactions that are terms of the form

A : swap(𝑥 : 𝜏 0 , 𝑦 * : 𝜏 1 )(2)

meaning that user A transfers 𝑥 : 𝜏 0 to the AMM {𝑟 0 : 𝜏 0 , 𝑟 1 : 𝜏 1 } specifying that she wants to receive back at least 𝑦 * units of token 𝜏 1 in return. The amount of token 𝑦 * must meet the constraint 0 < 𝑦 * ≤ 𝑦 where 𝑦 = 𝑥 • 𝑆𝑋(𝑥, 𝑟 0 , 𝑟 1 ) (see below for 𝑆𝑋) to preserve the constant-product swap rate of the reserve. In our mechanism, 𝑦 * represents a minimum acceptable threshold for the amount of token a user expects to receive from an exchange with an AMM reserve. A transaction will be rejected if the swap rate does not ensure the user receives at least this amount. Users submit their actions without knowing whether they will be executed at the resulting swap rate. In our formalization, we adopt the Constant Product Market Maker (CPMM) which is one of the most popular forms of DEX that considers a trade valid if the value of the reserve before and after (with an additional amount for fees) is constant or simply the same. More precisely, we consider the constant product swap rate that is the most commonly implemented in Uniswap [8], SushiSwap [9], and Curve [10] protocols. We use the swap rate function in all instances throughout this paper. In particular, when a user swaps a token 𝜏 0 with an AMM {𝑟 0 : 𝜏 0 , 𝑟 1 : 𝜏 1 }, the actual amount 𝑦 of 𝜏 1 is calculated using the following formula:

𝑆𝑋(𝑥, 𝑟 0 , 𝑟 1 ) = 𝑟 1 (𝑟 0 + 𝑥)(3)

This rate ensures that the evolution and the update of an AMM from {𝑟 0 : 𝜏 0 , 𝑟 1 : 𝜏 1 } to {𝑟 0 + 𝑥 : 𝜏 0 , 𝑟 1 − 𝑦 : 𝜏 1 } preserve the ratio between the reserve maintaining a constant level of tokens:

𝑟 0 • 𝑟 1 = (𝑟 0 + 𝑥) • (𝑟 1 − 𝑥 • 𝑟 1 𝑟 0 + 𝑥 ) = 𝑟 0 • 𝑟 1(4)

The formula above is derived by substituting the definition of 𝑆𝑋(𝑥, 𝑟 0 , 𝑟 1 ) from the equation (3) in place of 𝑦, then, by performing some algebraic simplification to obtain again 𝑟 0 • 𝑟 1 . The actions that result in overdrafts on users' balances are not immediately executed but are stored in a queue Λ.

Formally, a queue is a term obtained by the following grammar:

Λ := ∅ | Λ ∘ 𝑠(5)

where ∅ denotes an empty queue with no pending actions, and Λ ∘ 𝑠 a queue Λ where its head is the action 𝑠. In the semantic rules below, we use Λ ∘ 𝑠 to represent when an action 𝑠 is added to the queue Λ. Moreover, we write |Λ| to indicate the size of the queue Λ. For instance, ∅ is an empty queue with no pending action; while the term ∅ ∘ 𝑠1 denotes a queue with a single action 𝑠 1 that is equal to A : swap(6 : 𝜏 1 , 4 : 𝜏 0 ); and the term ∅ ∘ 𝑠1 ∘ 𝑠2 denotes a queue with two actions: the tail is 𝑠 1 = A : swap(6 : 𝜏 1 , 4 : 𝜏 0 ) and the head is 𝑠 2 that corresponds to B : swap(4 : 𝜏 2 , 6 : 𝜏 1 ). The LTS states are configurations defined as a 3-tuple ⟨Γ, Γ ′ , Λ⟩ where the first component is a state Γ of the form (1), the second one Γ ′ is the last simulated state (see the next subsection), and the third one is a swap action queue Λ of the form (5) of size ℓ. Given a state Γ we define ⟨Γ, Γ, ∅⟩ as an initial configuration.

AMM semantics

Transitions ⟨Γ, Γ ′ , Λ⟩ 𝑠 − → ⟨Γ ′′ , Γ ′′′ , Λ ′ ⟩ from a configuration to another one are triggered when a user submits a transaction 𝑠, and are defined by the inference rules below.

It is convenient to introduce some notation for the semantics. We say that a state Γ is green when the token supply of each user is non-negative, formally:

∀ A ∈ A ∩ Γ, 𝜏 ∈ T, s.t. 𝜎 A (𝜏 ) ≥ 0

where we denote with A ∩ Γ the set of users occurring in the configuration Γ. While we say it is red otherwise, namely if

∃ A ∈ A ∩ Γ, 𝜏 ∈ T, s.t. 𝜎 A (𝜏 ) < 0

Moreover, we denote with Γ 𝑠 = ⇒ Γ ′ a simulation of the transaction 𝑠 in the state Γ using the semantic rules of [7] without constraints on users' balances. This is why we want to maximize the number of settled actions performed by users. Differently, we maintain checks to impose non-negativity constraints on the AMM reserve. This means that some user balances could be negative in the resulting state Γ ′ but not AMM reserves. Given a sequence of transactions Λ, we denote with Γ Λ = ⇒ Γ ′ the simulation of the actions in Λ. Also, we assume that when Λ is the empty sequence 𝜖, the simulation results in an unchanged state, i.e., Γ 𝜖 = ⇒ Γ. When a transition is triggered by an action 𝑠 in a configuration ⟨Γ, Γ ′ , Λ⟩,

we have three possible scenarios.

The first scenario arises when the simulation of 𝑠 in Γ ′ reaches a green state Γ ′′ . In this case, we apply the following rule:

Γ ′ 𝑠 = ⇒ Γ ′′ Γ ′′ green ⟨Γ, Γ ′ , Λ⟩ 𝑠 − → ⟨Γ ′′ , Γ ′′ , ∅⟩

Cover

The rule Cover performs all the pending actions in Λ (if any), and the resulting configuration consists of the green state, Γ ′′ (in the first two components), and the emptied queue.

The second scenario happens when the simulation of 𝑠 in Γ ′ reaches a red state Γ ′′ , and the length of Λ is less than ℓ (max queue size, a parameter of our mechanism). In this case, we apply the following rule:

Γ ′ 𝑠 = ⇒ Γ ′′ Γ ′′ red |Λ| < ℓ Λ ′ = Λ ∘ 𝑠 ⟨Γ, Γ ′ , Λ⟩ 𝑠 − → ⟨Γ, Γ ′′ , Λ ′ ⟩ Overdraft

The rule Overdraft enqueues 𝑠 in Λ, thus, the resulting configuration consists of the current state Γ, the red state Γ ′ , and Λ ′ that is Λ extended with the incoming action 𝑠.

The last scenario occurs when the simulation of 𝑠 leads to a red state Γ ′′ , and the length of Λ equals ℓ. In this case, we use the netting procedure (denoted by the function 𝑛𝑒𝑡 in the following rule) to perform the settlement from the state Γ and the actions of Λ plus 𝑠.

The netting procedure identifies and returns a (possibly empty) sequence of feasible actions Λ ′ . Such sequence is a subset of the input sequence Λ. The obtained subsequence Λ ′ is executed to obtain the resulting state Γ * . All the other actions of Λ that are not selected by the procedure are discarded.

The resulting configuration is a 3-tuple with the state Γ * (for the first two components) and the empty queue for the last one (the queued actions were carried out or discarded). Formally, we apply the following rule:

Γ ′ 𝑠 = ⇒ Γ ′′ Γ ′′ red |Λ| = ℓ Λ ′ = net(Γ, Λ ∘ 𝑠) Γ Λ ′ = ⇒ Γ * ⟨Γ, Γ ′ , Λ⟩ 𝑠 − → ⟨Γ * , Γ * , ∅⟩

Netting

It is worth remarking that the mechanism provided in this section is agnostic with respect to the netting procedure that we invoke in a black-box manner. For example, a simple procedure could be to discard all enqueued transactions. The next section introduces a more meaningful procedure. Also, we remark that when we apply the above rule, the queue Λ contains a prefix of actions leading to a red state that is not balanced by other actions in the queue. Otherwise, the rule Cover would be applicable. The rule invokes the netting procedure to execute a subset of actions that allows the AMM to progress. Finally, note that our configurations and semantic rules could be written without Γ ′ (the 2nd component of the configuration recording the simulated/speculative final state) and replacing the premise

Γ ′ 𝑠 = ⇒ Γ ′′ with Γ Λ∘𝑠 ==⇒ Γ ′′ .

This approach requires re-computing the final state every time a new action is performed. These re-computations are not efficient in an implementation where it is more convenient to store the intermediate state. We decided to follow this approach to make our formalization coherent with the implementation.

Netting problem

Here, we provide an algorithm for the netting procedure 𝑛𝑒𝑡 invoked in Netting rule above. The netting problem is defined as follows: Given as inputs a state Γ, a queue Λ, find a subset Λ ′ of Λ, whose actions lead to a green state Γ * from Γ. Recall that the liquidity constraints required to each user are satisfied in a green state. Ideally, netting aims at finding an optimal solution, maximizing a specific parameter. For example, one may want to maximize the size of Λ ′ , the number of users affected, or the amount of tokens involved. We formalize the netting as an optimization problem that, given as inputs a state Γ of the LTS and a queue Λ, maximizes the size of Λ ′ , a queue, whose actions bring to a valid state Γ * that meet the liquidity constraints:

max |Λ ′ |(6)

subject to

Γ Λ ′ − → Γ * (7) Γ * green(8)

Note that the liquidity constraints (8) are satisfied if the final state Γ * is a green (there is no overdraft in users' wallets). The problem in financial literature is known as bank payment clearance, which is NP-hard [4,11], so we adopt a heuristic algorithm to implement the netting procedure that avoids enumerations and tries to maximize the number of transactions performed. Since we need an algorithm that can run on a smart contract (thus incurring affordable gas expenses), we adopt a heuristic approach that sacrifices optimality for efficiency, and we propose Algorithm 1 that runs in polynomial time (quadratic in the size of the queue, at worst).

Algorithm 1 Heuristic netting procedure implementationInput: Λ = [𝑠 1 , 𝑠 2 , . . . , 𝑠 𝑙 ], Γ Output: Λ 𝑟 Initialization: Λ 𝑟 ← Λ, Γ 0 ← Γ 1: Γ 0 Λ𝑟 = = ⇒ Γ 𝑙 ◁ Starting simulation 2: while Γ 𝑙 red ∧ Λ 𝑟 ̸ = ∅ do ◁ FinalΓ 𝑖 𝑠 𝑖+1 = == ⇒ Γ 𝑖+1 𝑠 𝑖+2 = == ⇒ Γ 𝑖+2 • • • 𝑠 𝑓 = ⇒ Γ 𝑓 7:

Γ 𝑙 ← Γ 𝑓 ◁ Update the variable Γ 𝑙 8: end while 9: return Λ 𝑟 Intuitively, Algorithm 1 simulates the swap actions ignoring the liquidity constraints. It starts by initializing Λ 𝑟 with Λ, the initial queue of pending actions, and Γ 0 with Γ, the initial state.

It then starts a loop (line 2), where it simulates action execution until either the final state Γ 𝑙 is not red or the queue Λ 𝑟 becomes empty, namely, until there are still actions to be processed and overdrafts in the system. During each iteration, we select from Λ 𝑟 the first action 𝑠 𝑖 that makes the balance of some account A become negative, i.e., the execution of 𝑠 𝑖 leads Γ 𝑙 to red state (line 3). Then, the algorithm removes 𝑠 𝑖 from Λ 𝑟 (line 4) and updates the simulation state Γ 𝑖 (line 5) by reverting 𝑠 𝑖 . We achieve that by simply considering the previous state Γ 𝑖−1 that is the last green state. After we recover to the last green state, the simulation is run again but from Γ 𝑖 using the actions following 𝑠 𝑖 until all balances are non-negative. As a result of this last simulation, we obtain the green state Γ 𝑓 (line 6). Finally, Γ 𝑙 is updated with the final state Γ 𝑓 (line 7) and the loop starts again.

These steps are iterated until we obtain a green state or empty Λ 𝑟 . When this happens, the algorithm returns Λ 𝑟 . In the following section, we provide an example of execution of Algorithm 1.

Liquidity-saving behavior

Our mechanism enables liquidity-saving behavior that is not possible in ordinary AMMs. An example is the simultaneous change of tokens through AMMs that we presented in Section 2. Another interesting behavior enabled by our mechanism is the ability to perform arbitrage on multiple AMMs simultaneously and with no liquidity.

Liquidity-saving arbitrage Example

Assume to have three AMMs with the following token reserves {8 : 𝜏 0 , 18 : 𝜏 1 }, {8 : 𝜏 1 , 18 : 𝜏 2 }, {8 : 𝜏 2 , 18 : 𝜏 0 } If we assume, a 1-to-1 exchange rate, we could see three arbitrage opportunities, only available to users with sufficient funds. Now suppose that a user A has no tokens but wants to perform the following actions 𝑠 1 𝑠 2 𝑠 3 :

A : swap(4 : 𝜏 0 , 6 : 𝜏 1 ), A : swap(4 : 𝜏 1 , 6 : 𝜏 2 ), A : swap(4 : 𝜏 2 , 6 : 𝜏 0 ) When considering AMMs without our mechanism, all the actions are discarded because A does not have an upfront balance. Figure 2 shows a flow diagram of the actions performed adopting our mechanism. Now 𝑠 1 𝑠 2 are enqueued because they cause an overdraft that is then covered by 𝑠 3 . The execution of 𝑠 3 results in the following green state:

[A[2 : 𝜏 0 , 2 : 𝜏 1 , 2 : 𝜏 2 ]|{12 : 𝜏 0 , 12 : 𝜏 1 }|{12 : 𝜏 1 , 12 : 𝜏 2 }|{12 : 𝜏 2 , 12 : 𝜏 0 }]

The above scenario has similarities with the traditional finance scenario known as gridlock [6] where banks cannot settle their payments individually due to their insufficient liquidity. Through netting, each bank submits its payment instructions to designated queues, performing multilateral settlement exclusively for the net obligations. Back to our example, user A overcomes the stuck state with possible no evolution of the system of traditional AMMs protocol where individual swap incurs in an overdraft, enqueuing her actions and atomically perform them when reaching a positive balance.

The approach we developed may settle transactions on the blockchain differently than the ones used by standard AMM protocols: netting can select transactions that the standard approach discards and vice versa. This difference may affect users' rewards and lead them to apply new/different market strategies. The following scenario exemplifies a case in which the netting of transactions could prevent swaps that would otherwise be executed.

Two Users scenario Example

Consider a scenario where there are two users A and B and two AMMs with the following wallets and reserves: Assume that user A wants to perform two actions. The first one, 𝑠 1 = A : swap(6 : 𝜏 1 , 4 : 𝜏 0 ), on the first AMM, {12 : 𝜏 0 , 12 : 𝜏 1 }, and the second one, 𝑠 2 = A : swap(4 : 𝜏 2 , 6 : 𝜏 1 ) on the second AMM, {18 : 𝜏 1 , 8 : 𝜏 2 }. User B wants to perform an action 𝑠 3 = B : swap(6 : 𝜏 1 , 4 : 𝜏 0 ) on the first AMM.

[A[0 : 𝜏 0 , 0 : 𝜏 1 , 4 : 𝜏 2 ]|B[4 : 𝜏 0 , 6 : 𝜏 1 , 0 : 𝜏 2 ]|{12 : 𝜏 0 , 12 : 𝜏 1 }|{18 : 𝜏 1 , 8 : 𝜏 2 }] User A [0 : 𝜏 0 , 0 : 𝜏 1 , 0 : 𝜏 2 ] AMM 1 {8 : 𝜏 0 , 18 : 𝜏 1 } AMM 2 {8 : 𝜏 1 , 18 : 𝜏 2 } AMM 3 {8 : 𝜏 2 , 18 : 𝜏 0 } 𝑠 1 = A : swap(4 : 𝜏 0 , 6 : 𝜏 1 ) A[−4 : 𝜏 0 , 6 : 𝜏 1 , 0 : 𝜏 2 ]|𝐴𝑀 𝑀 1 {8 : 𝜏 0 , 18 : 𝜏 1 } 𝑠 2 = A : swap(4 : 𝜏 1 , 6 : 𝜏 2 ) A[−4 : 𝜏 0 , 2 : 𝜏 1 , 6 : 𝜏 2 ]|𝐴𝑀 𝑀 2 {12 : 𝜏 1 , 12 : 𝜏 2 } 𝑠 3 = A : swap(4 : 𝜏 2 , 6 : 𝜏 0 ) A[2 : 𝜏 0 , 2 : 𝜏 1 , 2 : 𝜏 2 ]|𝐴𝑀 𝑀 3 {12 : 𝜏 2 , 12 : 𝜏 0 }

User A When considering an AMM without our mechanism, 𝑠 1 and 𝑠 2 are discarded because A does not have enough balance, whereas 𝑠 3 is performed reaching the configuration:

[0 : 𝜏 0 , 0 : 𝜏 1 , 4 : 𝜏 2 ] AMM 1 {12 : 𝜏 0 , 12 : 𝜏 1 } AMM 2 {18 : 𝜏 1 , 8 : 𝜏 2 } User B [4 : 𝜏 0 , 6 : 𝜏 1 , 0 : 𝜏 2 ] 𝑠 1 = A : swap(6 : 𝜏 1 , 4 : 𝜏 0 ) A[4 : 𝜏 0 , −6 : 𝜏 1 , 4 : 𝜏 2 ]|𝐴𝑀 𝑀 1 {8 : 𝜏 0 , 18 : 𝜏 1 } 𝑠 2 = A : swap(4 : 𝜏 2 , 6 : 𝜏 1 ) A[4 : 𝜏 0 , 0 : 𝜏 1 , 0 : 𝜏 2 ]|𝐴𝑀 𝑀 2 {12 : 𝜏 1 , 12 : 𝜏 2 } 𝑠 3 = B : swap(6 : 𝜏 1 , 4 : 𝜏 0 ) B[8 : 𝜏 0 , 0 : 𝜏 1 , 0 : 𝜏 2 ]|𝐴𝑀 𝑀 1 {8 : 𝜏 0 , 18 : 𝜏 1 }[A[0 : 𝜏 0 , 0 : 𝜏 1 , 4 : 𝜏 2 ]|B[8 : 𝜏 0 , 0 : 𝜏 1 , 0 : 𝜏 2 ]|{8 : 𝜏 0 , 18 : 𝜏 1 }|{18 : 𝜏 1 , 8 : 𝜏 2 }]

Differently with our mechanism 𝑠 1 is enqueued, and when A performs 𝑠 2 on the second AMM, both actions are settled because 𝑠 2 covers the overdraft on A's wallet (see Figure 3). While 𝑠 3 is not executed on the first AMM because the execution of the previous actions changes the ratio in the reserve, and hence the swap rate. Once 𝑠 1 𝑠 2 are performed, the ratio of the first AMM is updated and 𝑠 3 is discarded (as the red and crossed box denotes in Figure 3) because user B can swap 6 tokens of 𝜏 1 with 2 tokens of 𝜏 0 that is a different swap amount compared to what she wants to perform (6 tokens of 𝜏 1 with 4 tokens of 𝜏 0 ). This example highlights that the standard mechanism and ours generally settle different transactions, so they are incomparable. However, the behavior is not uncommon from what happens in ordinary AMMs where a user (in this case B) would typically decide to trade at a swap rate based on his local view or speculation on the state of AMMs, which can of course change if transactions of other users (in this case A) are executed.

Netting scenario Example

Consider a scenario where there is user A and three AMMs with the following wallet and reserves:

[A[0 : 𝜏 0 , 0 : 𝜏 1 , 4 : 𝜏 2 ]|{12 : 𝜏 0 , 12 : 𝜏 1 }|{18 : 𝜏 1 , 8 : 𝜏 2 }|{12 : 𝜏 2 , 12 : 𝜏 0 }]

Assume user A wants to execute three actions sequentially: 𝑠 1 , 𝑠 2 , and 𝑠 3 . With 𝑠 1 user A swaps 6 tokens of type 𝜏 2 for 4 tokens of type 𝜏 0 on the third AMM, in symbols 𝑠 1 = A : swap(6 : 𝜏 2 , 4 : 𝜏 0 ). With 𝑠 2 user A swaps 6 tokens of type 𝜏 1 for 4 tokens of type 𝜏 0 on the first AMM, namely 𝑠 2 = A : swap(6 : 𝜏 1 , 4 : 𝜏 0 ). Finally, with 𝑠 3 user A exchanges 4 tokens of type 𝜏 2 for 6 tokens of type 𝜏 1 on the second AMM: Upon executing the three actions illustrated in Figure 4, the system achieves a red state where the user's wallet fails to meet liquidity constraints. Consequently, our mechanism triggers the Netting rule and runs the Algorithm 1. During this process, 𝑠 1 is identified as the first action leading to an overdraft in A's wallet (see line 3 of Algorithm 1), and is thus removed from the queue. After this adjustment, the simulation is run again, resulting in a green state, achieved through the execution of 𝑠 2 followed by 𝑠 3 . It is worth noting that without 𝑠 1 , 𝑠 3 covers the overdraft caused by 𝑠 2 , thus, the reached state is green. This example illustrates how our netting mechanism manages transactions while considering liquidity constraints: our mechanism enables the execution of two actions that subsequently cover the balance overdraft, which would typically not be feasible using a standard semantics to execute the transactions.

𝑠 3 = A : swap(4 : 𝜏 2 , 6 : 𝜏 1 ). User A [0 : 𝜏 0 , 0 : 𝜏 1 , 4 : 𝜏 2 ] AMM 1 {12 : 𝜏 0 , 12 : 𝜏 1 } AMM 2 {18 : 𝜏 1 , 8 : 𝜏 2 } AMM 3 {12 : 𝜏 2 , 12 : 𝜏 0 } 𝑠 1 = A : swap(6 : 𝜏 2 , 4 : 𝜏 0 ) A[4 : 𝜏 0 , 0 : 𝜏 1 , −2 : 𝜏 2 ]|𝐴𝑀 𝑀 3 {18 : 𝜏 2 , 8 : 𝜏 0 } 𝑠 2 = A : swap(6 : 𝜏 1 , 4 : 𝜏 0 ) A[8 : 𝜏 0 , −6 : 𝜏 1 , −2 : 𝜏 2 ]|𝐴𝑀 𝑀 1 {8 : 𝜏 0 , 18 : 𝜏 1 } 𝑠 3 = A : swap(4 : 𝜏 2 , 6 : 𝜏 1 ) A[8 : 𝜏 0 , 0 : 𝜏 1 , −2 : 𝜏 2 ]|𝐴𝑀 𝑀 2 {12 : 𝜏 1 , 12 : 𝜏 2 }

Related work

The widely spread interest in distributed ledger technology has fostered the development of optimized trading protocols. This section illustrates the most relevant proposals concerning netting mechanism, optimal routing problems, and intent-centric protocols, and compares them with our work.

Netting mechanism

Several papers have developed decentralized inter-bank payment systems where the role of the payment instructions operator is implemented through a public ledger-based protocol, and the netting mechanism through smart contracts. As a first example of this line of work, Jasper-Ubin Project [12] investigates the possibility of achieving near-instant cross-border payments using blockchain. The project removes the single point of failure and obtains an immediate settlement without transaction reconciliation but does not give a decentralized multilateral netting. Naganuma et al. [13] provide a secure netting protocol using the Hyperledger Fabric channel and its access control mechanism. Their secure settlement protocol does not require a specific central server and keeps part of the payment transaction information secret. Similarly, Wang et al. [14] introduce a blockchain-based netting solution that relies on a central party and preserves the total amount of liquidity, revealing only the net amount of each bank. Cao et al. [6] propose a non-interactive zero-knowledge proof mechanism to post payment instructions on a public ledger. More precisely, each bank locally computes the netting results and submits its proposal to a coordinating smart contract. However, this approach is not robust against cheating users, who can post-invalid partial netting proposals. The proposals above consider blockchain-related technologies to develop standard financial services, whereas our work introduces a standard financial mechanism into DeFi protocols. To the best of our knowledge, ours is the first attempt to apply LSM used by the works above [13,14,6] to DeFi services.

Optimal routing problems

Another relevant research field investigates how to execute several trades of different crypto-assets on networks of multiple CFMMs. These approaches are known as routing problems on Decentralized Exchanges. Angeris et al. [15] and Diamandis et al. [16] pointed out that the optimal routing problem can be formulated as an efficiently solvable optimization problem. Solving such a problem means determining the most efficient path for a trade, i.e., a sequence of crypto-assets exchanges in a network of CFMMs that realizes a given trade, to maximize the user's utility and minimize its costs.

Danos et al. [17] introduce arbitrage scenarios within exchange networks and develop an effective global routing system. In detail, they explore how optimal routing strategies are employed to capitalize on price differentials across multiple exchanges, enhancing opportunities for profitable arbitrage. Similar to those approaches, our mechanism aims at finding a solution to maximizing a specific parameter. However, the main difference between ours and the above-mentioned papers [15,16,17] is the objective function to maximize. As illustrated in Section 3, our objective function consists of maximizing the number of actions in the queue, i.e., the number of transactions to settle. On the other hand, those proposals formulate the optimization problem in terms of the largest possible user's utility, and their routing problem tries to detect the most convenient and profitable route for executing trades across AMMs of the same and different token types belonging to the network.

Intent-centric protocols

A significant area of research in Ethereum ecosystem focuses on addressing the aggregated token swap problem, i.e., determining a sequence of swaps on AMMs that realizes a given trade by improving the liquidity of users. Various DeFi applications, such as UniswapX [18], Uniswap V4 [19], and CoW Protocol [20], tackle this challenge by adopting intent-centric protocols. These protocols shift the focus from transaction execution to defining users' desired outcomes, creating competitive routing marketplaces, introducing gas-free cross-chain swaps, and incorporating batch auctions to discover profitable prices.

UniswapX [18] implements intent-centric swaps, combining on-chain and off-chain liquidity for a competitive trading marketplace. Uniswap V4 [19] enhances liquidity with hooks, enabling gas-free cross-chain swaps and offering flexibility through customizable features. CoW Protocol [20] utilizes batch auctions for efficient price discovery, and CoW Swap, its decentralized exchange interface, introduces CoW Hooks, allowing custom actions before and after trades.

While these protocols aim to optimize trading across multiple AMMs, our approach stands out by introducing a Liquidity-Saving Mechanism designed to maximize users' swap actions without a formalized analysis of users' intent.

Conclusion

We have proposed liquidity-optimized AMMs, providing an LSM that settles AMM swap actions through a netting algorithm at the application level. We precisely characterized our mechanism by extending the operational semantics proposed by Bartoletti et al. [7]. We removed the liquidity constraints on participants' balances when performing swap actions and introduced a queue of actions. When the queue size reaches a fixed bound, and the liquidity constraints are unsatisfied, a greedy algorithm is triggered to compute a sequence of actions with no liquidity violation. Our mechanism enables novel scenarios, allowing users to perform exchanges and arbitrages without the required upfront funds.

In future work, we plan to extend our mechanism to deal with the deposit and redeem actions and take into account price trends, enabling us to consider realistic DeFi protocols. Moreover, we want to introduce the formalization of fixed transaction costs (such as gas costs) in the LTS. Another line of investigation is to understand if knowing the internals of the netting mechanism encourages users to misbehave and take advantage of it. Additionally, we want to extend our mechanism to take into account also other properties, such as, for example, fairness when selecting the actions to remove. Furthermore, we would like to study the impact of the queue length (a key parameter in our mechanism) on the efficiency of our LSM. We also plan to investigate the impact of validators at the consensus layer on our approach and whether they could be the ones promoting transaction orders that result in near-to-optimal queue orderings, hence taking care of the optimal netting problem.

Another line of research involves considering our mechanism work in different AMM models, such as Concentrated Liquidity which has been recently added to Uniswap v3 [21]. Furthermore, our formalization is designed to be implemented as a smart contract on the blockchain. It encompasses the management of various aspects such as user subscriptions, netting procedures with corresponding incentive mechanisms, queue management, and striking a balance between the mechanism's cost and the incentives it offers. An additional research direction involves exploring off-chain management of the actions, either through a trusted third party or in a decentralized manner. This approach aims to ensure the proper behavior of the queue, mitigating potential control issues by validators and simplifying the analysis of incentivized actions for each validator. Finally, we plan to re-model our mechanism, considering users' intents and trying to maximize their utility related to their desired outcome. In this way, we could better analyze user objectives and strategies.