Automated Market Makers are one of the most used Decentralized Finance services. They allow users to exchange crypto-assets without a third party. Current protocols have strong constraints related to the liquidity level that users' balances must satisfy for each transaction. In this paper, we propose a liquidity-saving mechanism that aims at reducing the required amount of liquidity in an AMM service. We provide an operational semantics of such a mechanism that precisely characterizes the interactions between users and AMMs and the conditions when the liquidity-saving mechanism is triggered. Our mechanism collects the proposed transactions in a finite queue, providing a global perspective of all users' actions. Starting from the queue, it finds a feasible transaction sequence that satisfies the users' balances. Finally, it performs these transactions on the blockchain atomically, reaching a state where all liquidity constraints are met. By doing so, the mechanism allows for novel liquidity saving behavior for multi-party exchange and multi-AMM arbitrage with less upfront liquidity as usually required.
In Decentralized Finance (DeFi) systems, Automated Market Makers (AMMs) are decentralized exchanges (DEXs) that provide users with liquidity using diferent reserves, enabling them to trade diferent 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 [
In this paper, we propose the design of an LSM for AMMs that ofers 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 [
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 efect 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 ineficiencies, facilitating the trading of assets more eficiently and cost-efectively. We discuss the scenarios where our proposed netting-based AMM and traditional AMM difer 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. [
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.
In current DeFi protocols, such as Uniswap [
This section formalizes our LSM, illustrates our netting algorithm, and shows how our approach difers from the standard one through some examples.
We formalize the interaction between users and AMMs as a labelled transition system (LTS). Our
semantics is based on those of Bartoletti et al. [
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: Γ = [A1[ A1 ]| · · · |
A[ A ] | {0 : 0, 1 : 1} | · · · | { : , : }] (1) ({ , ′} ̸= { , ′ }).
The labels of LTS are swap transactions that are terms of the form 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
A : swap( : 0, * : 1)
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 [
1 (0 + ) (2) (3) (4) (5) 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: 1 0 · 1 = (0 + ) · (1 − · 0 + ) = 0 · 1 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:
Λ := ∅ | Λ ∘ 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 .
submits a transaction , and are defined by the inference rules below.
Transitions ⟨Γ, Γ′, Λ→⟩− ⟨
Γ′′, Γ′′′, Λ′⟩ from a configuration to another one are triggered when a user
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 we have three possible scenarios. apply the following rule: otherwise, namely if where we denote with A ∩ Γ the set of users occurring in the configuration Γ. While we say it is red ∃ A ∈ A ∩ Γ, ∈ T, s.t. A( ) < 0
Moreover, we denote with Γ =⇒ Γ′ a simulation of the transaction in the state Γ using the semantic
rules of [
Γ′′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 eficient 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.
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 afected, 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 |Λ′|
subject to
Γ →−Λ′ Γ*
Γ* green
(6)
(7)
(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 [
Since we need an algorithm that can run on a smart contract (thus incurring afordable gas expenses), we adopt a heuristic approach that sacrifices optimality for eficiency, and we propose Algorithm 1 that runs in polynomial time (quadratic in the size of the queue, at worst).
Algorithm 1 Heuristic netting procedure implementation Input: Λ = [1, 2, . . . , ], Γ Output: Λ Initialization: Λ ← Λ, Γ0 ← Γ 1: Γ0 =Λ=⇒ Γ 6: 2: while Γ red ∧ Λ ̸= ∅ do 3: select s.t. ∈ Λ where A( ) < 0 4: 5: Λ ← Λ − Γ ← Γ− 1 Γ ===⇒ Γ+1 ==+=⇒2 Γ+2 · · · +1
=⇒ Γ 7: Γ ← Γ 8: end while 9: return Λ ◁ Starting simulation ◁ Final state has overdraft ◁ Select action that overdraft
◁ Update actions queue ◁ Update last green state ◁ Update the variable Γ
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.
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.
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 suficient funds. Now suppose that a user A has no tokens but wants to perform the following actions 123:
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 12 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 [
The approach we developed may settle transactions on the blockchain diferently than the ones used by standard AMM protocols: netting can select transactions that the standard approach discards and vice versa. This diference may afect users’ rewards and lead them to apply new/diferent market strategies. The following scenario exemplifies a case in which the netting of transactions could prevent swaps that would otherwise be executed.
Consider a scenario where there are two users A and B and two AMMs with the following wallets and reserves: [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] {8 : 0, 18 : 1} {8 : 1, 18 : 2}
Assume that user A wants to perform two actions. The first one, 1 = A : swap(6 : 1, 4 : 0), on the ifrst 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.
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:
[A[0 : 0, 0 : 1, 4 : 2]|B[8 : 0, 0 : 1, 0 : 2]|{8 : 0, 18 : 1}|{18 : 1, 8 : 2}] Diferently 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 12 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 diferent 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 diferent 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.
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: 3 = A : swap(4 : 2, 6 : 1).
User A [0 : 0, 0 : 1, 4 : 2]
AMM1
AMM2
AMM3
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.
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.
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. [
Another relevant research field investigates how to execute several trades of diferent 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 eficiently solvable optimization problem. Solving such a problem means determining the most eficient 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 efective global routing system. In detail, they explore how optimal routing strategies are employed to capitalize on price diferentials 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 diference 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 diferent token types belonging to the network.
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 of-chain liquidity for a competitive trading marketplace. Uniswap V4 [19] enhances liquidity with hooks, enabling gas-free cross-chain swaps and ofering flexibility through customizable features. CoW Protocol [ 20] utilizes batch auctions for eficient 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.
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. [
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 eficiency 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 diferent 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 ofers. An additional research direction involves exploring of-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.
This work was partially supported by project SERICS (PE00000014) under the MUR National Recovery and Resilience Plan funded by the European Union - NextGenerationEU. [9] A. Person, Sushi protocol documentation, https://docs.sushi.com/pdf/whitepaper.pdf, 2020. Accessed: 2024-03-12. [10] M. Egorov, Stableswap-eficient mechanism for stablecoin liquidity, Retrieved Feb 24 (2019) 2021. [11] Y. M. Shafransky, A. A. Doudkin, An optimization algorithm for the clearing of interbank payments,
European Journal of Operational Research 171 (2006) 743–749. [12] B. of Canada, M. A. of Singapore, Enabling cross-border high value transfer using distributed ledger technologies, https://www.mas.gov.sg/-/media/Jasper-Ubin-Design-Paper.pdf?la=en& hash=EF5857437C4857373A9287CD86F56D0E7C46E7FF, 2018. Accessed: 2023-07-11. [13] K. Naganuma, M. Yoshino, H. Sato, N. Yamada, T. Suzuki, N. Kunihiro, Decentralized netting protocol over consortium blockchain, in: International Symposium on Information Theory and Its Applications,ISITA 2018, IEEE, 2018, pp. 174–177. doi:10.23919/ISITA.2018.8664259. [14] X. Wang, X. Xu, L. Feagan, S. Huang, L. Jiao, W. Zhao, Inter-bank payment system on enterprise blockchain platform, in: 11th IEEE International Conference on Cloud Computing, CLOUD 2018, IEEE Computer Society, 2018, pp. 614–621. doi:10.1109/CLOUD.2018.00085. [15] G. Angeris, A. Evans, T. Chitra, S. Boyd, Optimal routing for constant function market makers, in:
Proceedings of the 23rd ACM Conference on Economics and Computation, 2022, pp. 115–128. [16] T. Diamandis, M. Resnick, T. Chitra, G. Angeris, An eficient algorithm for optimal routing through constant function market makers, arXiv preprint arXiv:2302.04938 (2023). [17] V. Danos, H. E. Khalloufi, J. Prat, Global order routing on exchange networks, in: Financial Cryptography and Data Security. FC 2021 International Workshops: CoDecFin, DeFi, VOTING, and WTSC, Springer, 2021, pp. 207–226. [18] UniswapX whitepaper, Uniswapx, https://uniswap.org/whitepaper-uniswapx.pdf, 2023. Accessed: 2024-01-21. [19] Uniswap V4 core whitepaper, Uniswap v4, https://github.com/Uniswap/v4-core/blob/main/docs/ whitepaper-v4.pdf, 2023. Accessed: 2024-01-21. [20] C. developers, Cow protocol, https://docs.cow.fi/, 2021. Accessed: 2023-10-10. [21] A. Hayden, Z. Noah, S. Moody, K. River, R. Dan, Uniswap v3, https://uniswap.org/whitepaper-v3. pdf, 2021. Accessed: 2024-04-23.