TW-AMM: A new idea for Dex to efficiently process large orders

Overview

This article introduces a new type of automated market maker (AMM) that can help traders on Ethereum execute large orders effectively.

We call it a time-weighted average market maker, abbreviated as TWAMM (pronounced “tee-wham”).

The working principle of TWAMM is to decompose long-term orders into infinitely small orders, and over time, automatically execute them for embedded constant product automation market makers.

Introduction

Suppose Alice wants to buy $100 million worth of ETH on the chain. It will be very expensive to execute orders of this size on an existing AMM like Uniswap. This is to prevent Alice from knowing some inside information they don’t know. , So it must charge Alice a high fee.

Now, Alice’s best option is to manually divide her order into several parts and execute them within a few hours, so that the market has time to realize that she has no inside information, so that she can give her a better price.

If she sends several large-scale sub-orders, then each order still has a significant impact on the price and is vulnerable to sandwich attacks by adversarial traders. On the other hand, if she sends many small-scale sub-orders, she will have to bear all the work and risks of active transactions, and will pay high costs to miners in the form of transaction gas fees.

Today, TWAMM has solved this problem for her by transacting on behalf of Alice. It breaks her orders into countless infinitely small virtual orders to ensure that they can be executed perfectly and smoothly over time, and uses a special function relationship with the embedded AMM to share the gas cost among these virtual orders. Since it deals with transactions between blocks, it is also less vulnerable to sandwich attacks.

Two basic concepts related to “market making”

1. a market maker

Consider that there are two financial assets in this market, such as USDC and ETH. The market maker is a participant in this market, and he hopes to be able to trade any asset with another asset at any time.

If you have 100 million USD in USDC and want to use it to buy ETH, you may not be able to find another person who wants to do the opposite transaction at the same time. Instead, you are likely to enter a market composed of one or more market makers and trade with them.

2. Adverse selection

The profit that market makers get from the spread is actually the fee they charge for each transaction. When the price trend is opposite to them, they will lose money-when they buy an asset and then the price drops, or sell an asset and the price rises.

Unfortunately, for market makers, price movements tend to be opposite to their operations. This phenomenon is called adverse selection. This happens because traders who learn about future price movements are more likely to make large transactions with market makers.

The most dangerous orders are those that are both large and urgent, because these are the types of orders that traders with inside information tend to place. Therefore, the most basic market-making strategy is “fade incoming orders”. When there is a big buy order, the price is increased, and when there is a big sell order, the price is decreased.

Automated Market Maker

In the past year, Automated Market Makers (AMM) represented by Uniswap have been very popular on Ethereum, processing billions of dollars in transactions every day. As the name suggests, AMM automates most of the market making process.

1. Constant trading formula

The constant trading formula is a simple rule that allows anyone to instantly create a new market and a new AMM for a new pair of assets.

In order to create a new constant transaction AMM (CPAMM) between the two assets of X and Y, users known as liquidity providers (LP) deposit reserves x and y for these two assets.

The ratio of these assets at any given time represents the immediate price on AMM, or the price it charges for a very small order. For example, if CPAMM’s reserves contain 2,000 USDC and 1 ETH, the instantaneous price of its ETH will be 2,000 USDC.

When a trader trades with AMM, it will decide what price to give them according to the formula **x * y = k, where x and y are the size of the reserve, and k is a constant. This means that the product of its reserve size remains constant during the transaction (ignoring fees).

2. Example

For example, an ETH/USDC CPAMM has 2,000 USDC and 1 ETH in its reserves, so x = 2,000 and y = 1, so x * y = k = 2,000. The instantaneous price of the AMM is 2,000 / 1 = 2,000 USDC per ETH.

If a trader comes to buy ETH worth 2,000 USDC, it means that they deposit a deposit of 2,000 USDC into X for reserve, so we will have x = 2,000 + 2,000 = 4,000.

Then, since k = 2000, we must get y = x/k = 2000/4000 = 0.5 after the transaction. Since y was initially 1, 1 – 0.5 = 0.5 ETH must have flowed to the trader.

Since traders bought 0.5 ETH with 2000 USDC, the average price they paid was 4,000 USDC per ETH. This high price relative to the instantaneous price reflects the large order size of AMM liquidity.

3. Price influence and adverse selection

In the above circumstances, when the cost of a small order is only 2,000 USDC per ETH, the trader must pay a fee of 4,000 USDC per ETH for his large order. This price difference is called the price effect of the order. The larger the scale of new orders, the greater the impact on prices.

This is how AMM counters adverse selection: large orders are more likely to be notified, so AMM will make them pay a high price. 

Execute large orders on the current AMM

1. Manually split orders

As we have seen, the transaction cost of executing a single large order on AMM is set high. This excellent article explores this problem in depth and recommends some solutions.

In short, traders who wish to execute large orders on AMM should not execute in a single transaction: they better divide the order into several parts. This may involve sending orders to multiple AMMs at once, but these AMMs have limited liquidity at any given point in time. Over time, the larger the order, the more meaningful it will be to split it.

For example, suppose an investor wants to buy $100 million in ETH on the chain, but since they don’t have any short-term information about the price of ETH, their order may take some time to execute. In this case, they may split the order into 10 orders, each order is 10 million US dollars, and execute an order every hour, thereby reducing the price impact of each order.

2. The trade-off of the size of sub-orders

Obviously, if a very large order is divided into several parts, then each individual sub-order will still be large and will have a corresponding price impact. At this time, it is useful to split the order into smaller ones, but this will also bring two new problems.

The first problem is the complexity of operations, which means increased risks and workload. The trader may split his transaction into the wrong amount or choose the wrong direction. On the other hand, his computer may crash in order to prevent the execution of some orders. And even if everything goes smoothly, this process requires time and effort, which will affect people’s attempts at more valuable things.

The second problem is that every transaction will incur fixed transaction costs, such as gas fees paid to Ethereum miners to process transactions. If a trader splits his order into too many parts, he may end up spending much more money than actually buying ETH.

Analogy with traditional finance

In the traditional financial sector, if investors or institutions want to buy $100 million in Apple stock, they will not directly send a $100 million market buy order to the exchange. Similarly, they will not send 10 orders worth $10 million. For the vast majority of people without specialized trading staff and infrastructure, it is impractical to divide orders into much smaller sub-orders.

Instead, they are likely to send large orders to the broker, who will perform algorithmic trading for them to earn fees. The broker will execute the transaction within a specified period of time, such as eight hours, and the price will refer to a certain standard. The broker has a team dedicated to executing such transactions safely and economically.

1. TWAP order

Perhaps the most basic type of algorithmic trading is the time-weighted average price or TWAP (pronounced “tee-whap”) order. As the name implies, if a TWAP order for Apple stock worth $100 million is executed within eight hours, it will eventually be traded at a price close to the time-weighted average price of Apple stock during that time period.

For example, if the price of Apple stock during this period of time is $100 for four hours and the price for the other four hours is $120, then the time-weighted average price will be ($100 * 4 + $120 * 4)/8 = $110 , The broker will execute TWAP orders close to this price.

Although the details of the operation are different, brokers are most likely to divide it into many small parts in a day and send them to the market to execute this transaction. Buying 100 million US dollars of Apple stock in 8 hours is equivalent to buying about 350 US dollars of Apple stock every 100 milliseconds. We should all expect brokers to perform similar operations.

Because brokers have professional infrastructure, these facilities can reduce or eliminate the operational complexity of so many small transactions, and because they have a direct connection with the market, they may not have to pay too much transaction costs.

Time-weighted average market maker

Time-weighted average market makers (TWAMM) provide the on-chain equivalent of TWAP orders. TWAMM relies on its unique logic algorithm for order splitting and direct connection with embedded exchanges to execute smooth transactions with lower gas fees. At the same time, arbitrageurs will keep the price of the TWAMM embedded exchange consistent with the market price to ensure execution near the time-weighted average price of the asset.

1 Overview

Each TWAMM facilitates transactions between specific asset pairs, such as ETH and USDC.

TWAMM contains an embedded AMM, which is the market maker of standard constant products for these two assets. Anyone can use this embedded AMM to trade at any time, as if it were an ordinary AMM.

Traders can submit long-term orders to TWAMM, which are orders to sell a fixed amount of an asset on a fixed number of blocks-for example, an order to sell 100 ETH in the next 2,000 blocks.

TWAMM decomposes these long-term orders into countless infinitely small virtual sub-orders, which will be traded with the embedded AMM at a constant speed over time. It is important to know that processing these virtual sub-order transactions separately will cost an infinite amount of gas, but the closed-form mathematical formula allows us to calculate their cumulative impact only when needed.

Over time, the execution of long-term orders will push the price of embedded AMM away from prices in other markets. When this happens, arbitrageurs will trade based on the embedded AMM price to keep it consistent, thus ensuring good execution of long-term orders.

If the long-term sale makes the ETH on the embedded AMM cheaper than the specific centralized exchange, then the arbitrageur will buy the ETH from the embedded AMM and sell it on the centralized exchange for profit when the price rebounds.

2. Ethereum update

2.1 Block

Ethereum packs transactions into continuous blocks, which are also called blocks, which are performed approximately every 13 seconds. In this article, we will number each block: block 1 is followed by block 2, then block 3, and so on.

2.2 Miners

Decentralized groups of miners began to race to process each block, and anyone who can connect to the Internet can become a miner. This means that running programs like AMM on Ethereum is not confidential: everyone must accurately calculate what will be produced given the input.

2.3 Gas cost

Computing power is a scarce resource on Ethereum, so users must pay miners in the form of gas fees. The greater the amount of calculation involved in a given transaction, the more gas it consumes. And this gas fee is completely paid by the person submitting the transaction.

3. Basic transaction design concept

3.1 Long-term orders

Alice wants to buy 100 million USDC worth of ETH in the next 8 hours, or about 2,000 blocks. She entered a long-term order in TWAMM to purchase 2,000 blocks of ETH worth 100 million USDC, which is equivalent to 50,000 USDC per block.

As mentioned above, we do not know in advance which miners will process these future transactions on TWAMM. This also means that Alice’s order must be visible to everyone, which leads to the information leakage problem that we will discuss below.

3.2 Order Pool

Suppose Bob wants to sell 500 ETH at USDC in the next 5,000 blocks, which is equivalent to selling 0.1 ETH per block.

Charlie wants to sell 100 ETH at USDC in the next 2,000 blocks, that is, 0.05 ETH per block.

When Charlie’s order expires within 2,000 blocks, Bob and Charlie’s orders will be combined in a pool.

The ETH sales pool will sell ETH at a price of 0.15 ETH per block in the next 2,000 blocks. Bob will receive 66% (0.1/0.15 ≈ 66%) of the USDC earned by the mining pool; Charlie will receive 33% (0.05/0.15 ≈ 33%) of the USDC earned by the mining pool.

3.3 Virtual Order

For the next 2,000 blocks, TWAMM must purchase 50,000 USDC worth of ETH on behalf of Alice and sell 0.15 ETH in USDC on behalf of the ETH sales pool.

We can imagine that TWAMM splits these two sub-orders into trillions of tiny sub-orders, which we call virtual orders (in fact, it splits them into countless infinitely small virtual orders).

Then TWAMM takes turns to execute these virtual orders against its embedded AMM: the first is Alice’s virtual order, then one in the ETH sales pool, then another order from Alice, and so on.

3.4 Arbitrage

Because Alice buys much more ETH than the ETH pool sells, the price of ETH on the embedded AMM will increase on each block.

When this price is high enough relative to the price of ETH in other places, arbitrageurs will buy cheaper ETH on other exchanges and sell it on the embedded AMM to keep the price in line with the market average and ensure better execution of Alice Orders. ‘

3.5 The order expires

After the 2,000th block, Alice’s order will be fully executed, as will Charlie’s order. Bob’s order to sell ETH is still valid for the next 3,000 blocks. During this period, TWAMM will continue to execute at a rate of 0.1 ETH per block.

Unless there are any other external activities, this will force the price of ETH on the embedded AMM to go down over time, and it will also encourage arbitrageurs to make the price rise once they are out of the price.

3.6 Token Economy

Because Alice, Bob, or Charlie are not eager to execute their orders, other market participants can infer that their orders represent less adverse selection than other situations, and can provide them with execution with low price impact.

Since TWAMM will be the best place for Alice, Bob and Charlie to conduct transactions, the LP on the TWAMM embedded AMM may interact with a large number of uninformed persons like them. This will also help LPs earn benefits from fees and reduce their risk of adverse selection.

4. Infinitesimal Virtual Orders

We mentioned above that TWAMM splits long-term orders into infinite infinitely small sub-orders. There are two reasons for this: fluency and efficiency.

4.1 Fluency

The main goal of TWAMM is to smoothly execute long-term orders over time so that they can execute trades at prices close to the current time-weighted average price.

As we reduce the size of virtual transactions, price changes on AMM have become more and more stable.

In extreme cases, because there are countless infinitely small transactions, the price changes very smoothly when performing virtual transactions.

TW-AMM: A new idea for Dex to efficiently process large orders

4.2 Efficiency

Since TWAMM was originally designed to be used in the Ethereum blockchain, the cost of explicitly calculating transactions for multiple virtual transactions in each block is very high. However, when we have an infinite number of infinitesimal transactions, we can calculate the result of the trader in one calculation, no matter how many blocks there have been since the last check.

implement

1. Lazy Evaluation

TWAMM treats virtual sub-orders as occurring in the space between blocks, which is important for avoiding sandwich attacks.

In order to achieve this in a way that saves gas costs, TWAMM uses lazy evaluation and only calculates the impact of virtual transactions when it is necessary to determine the outcome of the interaction.

Every time a user interacts with TWAMM (for example, by using an embedded AMM for trading or adding a new long-term order), TWAMM will retrospectively calculate the impact of all virtual transactions that have occurred since the last interaction.

Since these virtual transactions only interact with TWAMM’s embedded AMM, TWAMM behavior is completely deterministic between external interactions. Even if TWAMM moves 1 million blocks between external interactions, the next time someone interacts with it, it can still accurately calculate the results of all intervening virtual transactions.

For the front end that inserts TWAMM, it can process virtual transactions that have not yet been represented on the chain by tracking the current block number and performing TWAMM calculations on its own.

2. Gas optimization

2.1 Pooling Orders

As shown in the example, when we have multiple long-term orders in the same trading direction (that is, selling ETH in USDC), we will group them together and then split them into virtual orders. Then, TWAMM can use an algorithm to track balances, and this algorithm is the same as the version of the algorithm that tracks billions of dollars in LP token incentives in agreements such as Compound and Uniswap.

Technically speaking, each TWAMM always has two long-term order pools, one for each asset: for example, an order pool for selling USDC and an order pool for selling ETH. It is worth mentioning that at any given time, one or two of these order pools may be empty.

2.2 Long-Term Order Expiration

A complication arises when order pooling is used in conjunction with lazy evaluation.

Imagine that Bob places a long-term order to sell 100 ETH in the next 100 blocks, and Charlie also places an order to sell 200 ETH in the next 200 blocks, two orders They are all sold at a price of 1 ETH per block.

Assuming that no one interacts with TWAMM in the next 150 blocks, a new external interaction will occur at this time. In the first 100 blocks after Bob and Charlie place an order, their orders will be combined into a common order, and each block will sell 2 ETH. However, for the next 50 blocks, Charlie’s order becomes independent, and each block will only sell 1 ETH.

This means that we must perform two separate transaction calculations to find out what happened:

* Calculate the results of the first 100 blocks at a time;

* Calculate the results of the last 50 blocks at once.

In the worst case, if every block of the past 150 blocks has an order expiration, this means that TWAMM will have to process one transaction per block, thus destroying the gas efficiency.

To solve this problem, the simplest solution is to limit the number of blocks that meet the order expiration conditions: for example, TWAMM can specify that the order can only expire once every 250 blocks, or about once every hour.

2.3 Canceling Long-Term Orders

Users can cancel long-term orders at any time. In practice, this will allow users to choose a cancellation time for their own orders until the block completes the order transaction. In this case, the gas burden of the system will not increase, because all cancellation operations are decisions made by the users themselves, so they need to pay for the gas themselves.

3. Virtual Trade Math

3.1 Definition

Assume that t blocks have been generated since TWAMM executed any virtual transaction last time.

For the sake of simplicity, assume that there is no long-term order expiration. Therefore, during the entire time period, the mining pool that sells X sells x_{rate} for each block, and the mining pool that sells Y sells y_{rate} for the entire time period. part.

Then the total amount of X sold during this period is tx_{rate} = x_{in}, and the total amount of Y sold during this period is ty_{rate}=y_{in}.

Let us denote the AMM reserves embedded at the beginning of the time period as x_{ammStart} and y_{ammStart}, respectively.

3.2 Formula

After processing all virtual transactions, the reserve asset X that the embedded AMM will obtain is

TW-AMM: A new idea for Dex to efficiently process large orders

in

TW-AMM: A new idea for Dex to efficiently process large orders

From the constant product formula, we know

TW-AMM: A new idea for Dex to efficiently process large orders

The mining pool that sells X gets all the Y that does not appear in the embedded AMM-in other words,

TW-AMM: A new idea for Dex to efficiently process large orders

Similarly,

TW-AMM: A new idea for Dex to efficiently process large orders

Potential attack vector

1. Sandwich attack

1.1 Description

In the sandwich attack, the attacker Atticus saw that the trader Trey was about to trade on AMM. Atticus sent two orders, clamped Trey’s order, and profited from it.

Imagine that Trey sent an order to buy ETH with USDC to AMM. At this time, the order was discovered by Atticus, so Atticus placed an order before Trey and purchased ETH on AMM, which pushed the price up. Since he is paying AMM and has a price impact, Atticus is losing money on this order.

When Trey’s order was executed, he had to buy ETH at a higher price because Atticus pushed up the price. At this time, Trey’s actual order price was pushed up further.

Now Atticus sells his ETH back to AMM. Since Trey has pushed up the price of AMM since Trey bought, the price he sold is actually higher than the purchase price, so he can achieve profit.

However, only if Atticus can guarantee that Trey will sell his ETH back to AMM immediately after purchase, then this attack is meaningful to Atticus. In a given block, this type of attack is actually possible if Atticus is a miner, makes a transaction with a miner, or uses services such as Flashbots.

1.2 Sandwich orders and virtual orders

At first glance, virtual orders seem to be particularly vulnerable to sandwich attacks because everyone knows they will come.

However, because they are executed between a certain number of blocks, the order can be saved. A virtual order attacker who wants to “clamp” TWAMM must trade with the embedded AMM at the end of a block. This will cause the virtual order to be executed at a bad price between blocks, and then start in the next block. When trading in the other direction.

Currently, there is no way for attackers to guarantee that they will only trade at the end of a given block, because the premise of the attack is that they must trade at the beginning of the next block. When the maximum extractable value (MEV) of multiple blocks becomes more common and allows traders to be sandwiched between multiple blocks, the problem may become more serious.

2 Information leakage

The biggest tradeoff that long-term traders may encounter in TWAMM is that they face the risk of information leakage when placing “publicly visible” orders. Due to the nature of Ethereum, this risk is difficult to avoid.

If a trader places a large enough long-term order, other traders may want to trade before him/her and buy assets in TWAMM embedded AMM and other places in order to sell it back to the trade as a long-term order later Zhebin pushed up prices.

Since users can cancel their long-term orders at any time, we expect that over-aggressive large-order traders will be used by other traders. Therefore, we need to control the overall impact of information leakage.

2.1 Example

Imagine that Sally the fraudster has noticed an offensive preemptive trading opportunity on TWAMM. At this point, she can buy $1 million in ETH from a liquidity aggregator, which in turn pushes up the price of the entire market. Then, she can place a large long-term order on TWAMM, but in the next 24 hours, she will buy $100,000 in ETH on each block.

Frank quickly saw this large order and purchased $1 million in ETH through the aggregator, and the price was further pushed up. Next, Sally sells her ETH through the aggregator to make a profit. As a result, the price will be pushed down and Frank will suffer a loss. In the end, she cancelled her long-term order before the order was completed.

Python reference implementation

You can view the Python reference implementation of TWAMM here.

The Jupyter Notebook on GitHub shows the behavior of TWAMM, which contains multiple cancelled long-term orders and arbitrageur operations.

For simplicity, this Python version does not implement gas optimizations like pooled orders or true lazy evaluation.

in conclusion

We have outlined the design framework of TWAMM, but our work has just begun.

If you are interested in solving this or similar issues, you can contact Uniswap Labs by email or private message on Twitter.

Original Authors: Dave White, Dan Robinson, Hdyden Adams

 

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/tw-amm-a-new-idea-for-dex-to-efficiently-process-large-orders/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Leave a Reply