content
1 Introduction
2. Summary
3. The basis of market making
3.1 Market maker
3.2 Adverse selection
4. Automated market maker
4.1 Constant product formula
5. Execute large orders on the current AMM
5.1 Manually split orders
5.2 Sub-order size trade-off
6. Traditional financial analogy
6.1 TWAP order
7. Time-weighted average market maker (TWAMM)
7.1 Overview
7.2 Ethereum terminology review
7.3 Basic design
7.4 Infinitesimal Virtual Order
8. Implementation
8.1 Lazy Evaluation
8.2 Gas optimization
8.3 The mathematics involved in virtual trading
9. Potential attack vectors
9.1 Sandwich attack (also known as sandwich attack)
9.2 Information disclosure
10. Python reference implementation
11. Conclusion
1 Introduction
This article introduces a new type of automated market maker (AMM) that can help traders on Ethereum execute large orders effectively.
We call it the time-weighted average market maker, or TWAMM (pronounced “tee-wham”).
It works by decomposing long-term orders into infinitely many infinitely small orders and executing them smoothly over time according to the embedded constant product AMM.
2. Summary
Assuming that Alice wants to buy 100 million USDC worth of ETH on the chain, it will be expensive for her to execute orders of this size on existing AMMs such as Uniswap. If Alice knows something that others don’t know (inside information), then her Executing such large transactions will encounter great slippage.
Today, 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 and can therefore give her a better price.
If she sends several large sub-orders, and each sub-order will still have a significant impact on the market price, and will be vulnerable to sandwich attacks from counterparty traders. On the other hand, if she sends many small sub-orders, she will have to bear all the risks of work and active transactions, and pay a large amount of gas transaction fees to the miners.
TWAMM solves this problem by transacting on behalf of Alice. It decomposes Alice’s orders into infinitely many infinitely small virtual orders to ensure perfect and smooth execution over time, and uses a special mathematical relationship with embedded AMM to share the gas cost among these virtual orders. In addition, because TWAMM is a transaction executed between blocks, it is also less susceptible to sandwich attacks.
3. The basis of market making
3.1 Market maker
Consider a market composed of two financial assets (such as USDC and ETH), and market makers are participants in this market, and they are willing to trade one asset for another at any time.
If you have 100 million USDC and want to use it to buy ETH, you may not find another person to do the opposite transaction at the same time. Instead, you are likely to go to a market composed of single or multiple market makers and trade with them.
3.2 Adverse selection
Market makers profit from the spread, which is the fee they charge for each transaction. When prices are opposite to them, they lose money (for example, when they buy assets whose prices have fallen, or sell assets whose prices have risen.)
Unfortunately, for market makers, market prices are often the opposite of theirs. This phenomenon is called adverse selection. This happens because traders who have information about future price movements are more likely to conduct large transactions with market makers.
Generally speaking, the most dangerous orders are those that are large and urgent, because these are the types of orders that informed traders tend to place. Therefore, the most basic market-making strategy is to dilute the market entry order, that is, when a large number of buy orders come in, increase the price; when a large number of sell orders come in, reduce the price.
4. Automated market maker
In the past year, Automated Market Makers (AMMs) led by Uniswap have become very popular on Ethereum. These AMMs process billions of dollars in transactions every day. As the name suggests, AMM automates most of the market making process.
4.1 Constant product formula
The constant product 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 product AMM (CPAMM) between two assets X and Y, a user called a liquidity provider (LP) deposits x and y reserves of these two assets.
The ratio of these assets at any given time represents the real-time price on AMM. For example, if the reserve of CPAMM contains 2,000 USDC and 1 ETH, the instantaneous price of 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 the same during the transaction (ignoring fees).
example:
Consider an ETH/USDC CPAMM with 2,000 USDC and 1 ETH in its reserves, so at this time x = 2,000, y = 1 and x * y = k = 2,000. The instantaneous price of this 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 2,000 USDC in the X reserve, so our x becomes 4,000 (2000+2000).
Then, since k = 2000, after this transaction, our y becomes 0.5 (y = x/k=2000/4000). Since y was initially 1, 0.5 ETH flowed to the trader.
Since traders bought 0.5 ETH with 2000 USDC, the average price of ETH they paid was 4,000 USDC.
Price influence and adverse selection
Under the above circumstances, traders must pay 4000 USD/ETH for their large orders, while the cost of small orders is only 2000 USD/ETH. This price difference is called the price effect of the order. The larger the order, the greater the price impact (slippage).
This is how AMM fights against adverse selection: large orders are more likely to be related to inside information, so AMM makes them pay a high price. It is the automated equivalent of downplaying orders.
5. Execute large orders on the current AMM
5.1 Manually split orders
As we have seen, it is expensive to execute a large order to AMM in a single transaction. 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 them 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 also have limited liquidity at any given point in time. The larger the order, the more attractive it is to split it over time.
For example, suppose an investor wants to buy 100 million USDC worth of ETH on the chain. They don’t have any short-term information about the price of ETH, so they don’t mind if their orders will take some time to execute. In this case, they may split the order into 10 small orders, each order is 10 million US dollars, and executed every 1 hour, thereby reducing the price impact of the order.
5.2 Sub-order size trade-off
Obviously, if a very large order is split into several parts, each individual sub-order will still be large and will have a corresponding price impact. Dividing the order into smaller parts can help, but it introduces two new problems.
The first problem is operational complexity, which means increased risk and workload. Traders may enter the wrong number of trades or the wrong direction for a given trade. Or her computer may crash, preventing her from executing part of the order. Even if all goes well, this process will take time and energy, and it will distract people from more profitable efforts.
The second problem is that every transaction incurs a fixed transaction cost, such as gas paid to Ethereum miners to process the transaction. If a trader divides her order into too many parts, he may eventually consume more funds in transaction fees than the ETH he actually purchased.
6. Traditional financial analogy
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. They also won’t send 10 orders worth $10 million, and for most people who don’t have dedicated traders and infrastructure, it is impractical to divide orders into much smaller parts.
On the contrary, they are likely to send large orders to brokers, and the economic chamber of commerce will conduct algorithmic trading for them in exchange for fees. The broker will execute the transaction within a specified time period, such as eight hours, and the price is similar to a certain benchmark. The broker will have a team dedicated to executing such transactions safely and cheaply.
6.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 suggests, a TWAP order to buy $100 million worth of Apple stock within eight hours will be executed at a price close to the time-weighted average price of Apple stock during that period.
For example, if Apple stock is priced at $100 for four hours and $120 for the other four hours, then the time-weighted average price will be ($1004+$1204)/8=$110, and the broker will execute a price close to this price. TWAP order.
The details vary, but the broker is most likely to execute this transaction by dividing it into many small pieces in a day and sending them to the market. Buying $100 million of Apple stock in 8 hours is equivalent to buying about $350 of Apple stock every 100 milliseconds, and we might expect brokers to do this more or less.
Brokers have the infrastructure to 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.
7. Time Weighted Average Market Maker (TWAMM)
Time-weighted average market makers (TWAMM) provide the on-chain equivalent of TWAP orders.
TWAMM has dedicated logic for order splitting and a direct connection with embedded exchanges to provide smooth execution at low gas costs. Arbitrageurs 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.
7.1 Overview
Each TWAMM instance facilitates transactions between specific asset pairs, such as ETH and USDC.
TWAMM contains an embedded AMM, which is the standard constant product market maker 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 number of assets 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 an infinite number of infinitely small virtual sub-orders, and these sub-orders are traded with the embedded AMM at a uniform rate over time. Processing these virtual sub-order transactions alone will cost unlimited 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 price embedded in AMM to bring it back to consistency, thereby ensuring good execution of long-term orders.
For example, if long-term selling makes the ETH on the embedded AMM cheaper than a specific centralized exchange, the arbitrageur will buy the ETH from the embedded AMM, make its price rise, and then sell it on the centralized exchange for profit.
7.2 Ethereum terminology review
Block: Ethereum bundles transactions into continuous groups called blocks, approximately once every 13 seconds. For the purpose of this article, we will number each block: block 1 is followed by block 2, then block 3, and so on.
Miner: A distributed group of miners competes to process each block. Anyone who can connect to the Internet can become a miner, which means that programs like AMM running on Ethereum cannot keep any secrets: everyone must be able to accurately calculate what they will do with a given input .
Gas: Computing on Ethereum is a scarce resource, so users must pay miners in the form of gas. The more calculations involved in a given transaction, the more Gas it consumes. This gas fee is fully paid by the person submitting the transaction.
7.3 Basic design
Long-term order: 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 buy 100 million USDC worth of ETH in the next 2,000 blocks, or 50,000 USDC per block.
As mentioned above, we do not know in advance which miners will process future transactions on TWAMM. This means that Alice’s order must be visible to everyone, which introduces the information leakage problem we discuss below.
Order pool: Bob wants to convert 500 ETH into USDC in the next 5,000 blocks, or sell 0.1 ETH per block.
Charlie wants to convert 100 ETH into USDC in the next 2,000 blocks, which means that each block sells 0.05 ETH.
Until Charlie’s order expires in 2,000 blocks, Bob and Charlie’s orders will be grouped into a pool.
The ETH sales pool will sell ETH at a rate of 0.15 ETH per block in the next 2,000 blocks. Bob will get ≈ 66% (0.1/0.15) of the USDC pool, and Charlie will get ≈ 33% (0.05/0.15) of the USDC pool.
Virtual order:
For each of the next 2,000 blocks, TWAMM must buy 50,000 USDC worth of ETH on behalf of Alice and sell 0.15 ETH on behalf of the ETH sales pool in exchange for USDC.
We can imagine that TWAMM splits each of these two sub-orders into trillions of tiny sub-sub-orders, which we call virtual orders (in fact, they are broken down into countless infinitely small virtual orders).
Then TWAMM takes turns to execute these virtual orders against its embedded AMM: the first one is Alice’s virtual order, then one virtual order from the ETH sales pool, then another virtual order from Alice, and so on.
arbitrage:
Because Alice buys much more ETH than the ETH sales pool sells, the price of ETH on the embedded AMM will experience an increase in 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, bringing the price back to the market average level and ensuring Alice’s good execution.
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 which time TWAMM will continue to execute it at a rate of 0.1 ETH per block.
Unless there is any external activity, this will push down the price of ETH on the embedded AMM over time, this time prompting arbitrageurs to pull back to the market price after the price is completely out of line.
economics:
Since Alice, Bob, or Charlie are not in a hurry to execute orders, other market participants can infer that their orders represent less adverse selection than in other cases, and can provide them with execution with low price impact.
Since TWAMM will be the best place for people like Alice, Bob and Charlie to conduct transactions, the LP on the TWAMM embedded AMM may interact with a large number of unknown flows like them. This helps to make money from expenses while reducing the risk of adverse selection.
7.4 Infinitesimal Virtual Order
We mentioned above that TWAMM splits long-term orders into an infinite number of infinitely small sub-orders. There are two reasons for this: smoothness and efficiency
Smoothness
The main goal of TWAMM is to smoothly execute its long-term orders over time so that their execution price is close to the current time-weighted average price.
As we reduce the size of virtual transactions, price fluctuations on AMM become more and more irregular.
In the limit state, because there are infinitely many infinitely small transactions, when the virtual transaction is executed, the price movement is completely smooth.
See https://github.com/para-dave/twamm/blob/master/splitting_exploration.ipynb
efficiency
Since TWAMM is designed to be used in Ethereum, the transaction cost of explicitly calculating multiple virtual transactions for each block can be prohibitively high. However, when we have an infinite number of infinitely small transactions, we can calculate the trader’s result in one calculation (regardless of how many blocks there have been since the last check).
8. Implement optimization plan
8.1 Lazy Evaluation
TWAMM treats virtual sub-orders as occurring in the space between blocks, which is important to avoid sandwich attacks.
In order to achieve this in a gas-saving way, TWAMM uses Lazy Evaluation, which calculates the impact of virtual transactions only when the interaction result needs to be determined.
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, the behavior of TWAMM 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 accurately calculate the results of all intervening virtual transactions.
The front end that inserts TWAMM will be able to consider virtual transactions that have not yet been represented on the chain by tracking the current block number and performing TWAMM calculations on its own.
8.2 Gas optimization
Aggregate order
As shown in the example, when we have multiple long-term orders in the same direction (that is, sell ETH and exchange for USDC), we aggregate them and then split them into virtual orders. TWAMM can then track balances using the billion-dollar algorithm used to track LP rewards 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. At any given time, one or two of these order pools may be empty.
Long-term order due
A complication arises when the order pool is used in conjunction with deferred calculation.
Imagine that Bob places an order to sell 100 ETH in the next 100 blocks, and Charlie places an order to sell 200 ETH in the next 200 blocks. Both orders are sold at a rate 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. Their first order was a joint order between Bob and Charlie, which sold 2 ETH per block. However, in the 50 blocks after that, Charlie’s orders are independent, and each block only sells 1 ETH.
This means that we must perform two separate transaction calculations to find out what happened: once to calculate the result of the first 100 blocks, and once to calculate the result of the 50 blocks. In the worst case, if every block of the past 150 blocks has an order expiration, this means that TWAMM will have to process a transaction for each block, thereby destroying gas efficiency.
The simplest solution to this 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.
Cancel long-term orders
Users can cancel long-term orders at any time. In practice, this allows users to choose a cancellation time for their order. This will not increase the gas burden on the system, because users who want to cancel need to pay for the gas themselves.
8.3 The mathematics involved in virtual trading
definition:
Assume that there have been t blocks since TWAMM executed any virtual transaction last time.
For simplicity, it is assumed that there is no long-term order expiration, so the pool that sells X is sold at the rate of x_rate per block during the entire time period, and the pool that sells Y is sold at the rate of y_rate per block during the entire time period.
Then the total amount of X sold during this period is
, And the total amount of Y sold during this period is
.
Let us denote the AMM reserves embedded at the beginning of the time period as
as well as
.
formula:
After processing all virtual transactions, the embedded AMM will have X reserves
in
From this constant product formula, we know
The pool that sells X gets all Ys that do not appear in the embedded AMM, in other words,
And similar,
9. Potential attack vectors
9.1 Sandwich attack (also known as sandwich attack)
Description: In the sandwich attack, the attacker Atticus saw that the trader Trey was about to make a transaction on AMM, and then Atticus sent two orders and clamped Trey’s order to achieve profit.
Imagine that Trey sends an order to AMM to buy ETH with USDC. After seeing this order, the attacker Atticus preemptively bought ETH on AMM before rey, in order to push the price of ETH up. Since he is paying AMM and has a price impact, Atticus has lost money after operating this order.
When Trey’s order is executed, he will buy ETH at a higher price, because Atticus pushes up the price, and Trey’s order further pushes up the price of ETH.
Now, Atticus immediately sells his ETH back to AMM. At this time, the price he sold is higher than the price he bought, so he can achieve profit.
If Atticus can guarantee that Trey will sell his ETH back to AMM immediately after the purchase, then this attack will make sense to Atticus. Within a given block, this is possible if Atticus is a miner, makes a transaction with a miner, or uses services such as Flashbots.
Sandwich attacks and virtual orders
At first glance, virtual orders seem to be particularly vulnerable to sandwich attacks because everyone knows they will come.
But because they are executed between the ** blocks, it is not easy to attack. The attacker who wants to clamp the virtual order of TWAMM must trade with the embedded AMM at the end of a block, resulting in the virtual order in the zone. Blocks are executed at a bad price, and then traded in the other direction, ending the transaction at the beginning of the next block.
At present, the attacker has no way to guarantee the implementation of this type of attack. When this multi-block MEV becomes more common, allowing traders to conduct sandwich transactions between multiple blocks, this may become a bigger problem.
9.2 Information disclosure
The biggest trade-off that long-term traders may encounter in TWAMM is that they will face the problem of information leakage when placing publicly visible orders, which is caused by the nature of Ethereum.
If a trader places a large enough long-term order, other traders may try to preemptively buy assets in TWAMM’s embedded AMM and other places in order to sell them to the trader after the long-term order pushes up the price.
Since users can cancel their long-term orders at any time, we expect that overly aggressive early traders will be used by other traders to control the overall impact of information leakage.
example:
Imagine that Sally the scammer has noticed aggressive preemptive transactions on TWAMM. She bought 1 million USDC worth of ETH from a liquidity aggregator, thereby pushing up the price of the entire market. Then she placed a huge long-term order on TWAMM to buy 100,000 USDC of ETH per block in the next 24 hours.
The lead trader Frank immediately saw the order and purchased 1 million USDC worth of ETH through the aggregator, which further pushed up the price. Sally used the aggregator to sell her ETH back for profit, which caused the price of ETH to drop and Frank suffered a loss. In the end, she cancelled her long-term order before any order was completed.
10. Python reference implementation
You can view the Python reference implementation of TWAMM here.
This Jupyter note demonstrates TWAMM in the presence of multiple long-term orders and arbitrageurs.
For the sake of simplicity, this Python version does not implement gas optimizations, such as order pool order or true delay calculation.
11. Conclusion
We have outlined the design of TWAMM, but our work has just begun. If you are interested in resolving this problem or a similar problem, you can send an email to [email protected] or give me on Twitter send private messages, or you can also [email protected] contact Uniswap Labs.
Acknowledgements: Sam Sun, Georgios Konstantopoulos, Michael Bently, Michael Kustermann, Kevin Pang, Hasu, Sam Bankman-Fried, Henry Prior, Tom Cadwell, Alex Wice, Mewny, Big Magic, Lily Francus, Tarun Chitra, Moody Salem, Noah Zinsmeister, Teo Leibowitz.