Here is what we are going to cover:

• FraxSwap core concept of TWAMM
• Working of TWAMM
• Issues solved via TWAMM

This article goes in-depth in explaining the intricacies of the core TWAMM built on the AMM of Fraxswap. TWAMM allows the execution of large orders without creating a large price impact.

In trading, liquidity depth. demand and supply, price, and trade execution time are the variables one interacts with. One cannot gain an advantage in every aspect of these factors. TWAMM allows larger orders at the cost of trade duration.

If this simple reading layout doesn’t excite you, you could scroll down to consume the same content as if it were a magazine.

⚠ Disclaimer: All information presented here is my perspective and should be considered educational content. I won’t be responsible for any kind of financial profits or losses derived from your decisions. Financial and investment advice

Fraxswap is the first constant product automated market maker with an embedded time-weighted average market maker (TWAMM) for conducting large trades over long periods of time trustlessly.

As per Frax protocol, they may use Fraxswap for: buying back & burning $FXS with AMO profits, minting new $FXS to buy back & burn $FRAX stablecoins to stabilize the price peg, minting $FRAX to purchase hard assets through seigniorage, and many more market operations in development.

TWAMM: The concept

To understand the working of a TWAMM an example need to consider where a trader wants to execute a swap order in a decentralized exchange.

Suppose Joe has sure-shot information that $ETH is going to rally, Joe will accumulate his capital and privacy reasons he is choosing a decentralized exchange over a centralized one. He chooses an AMM working on the constant product function, the liquidity pool composes of 2000 $USDC and 1 $ETH making the exchange price of $2000 for 1 ETH.

If Joe accumulated $2000 USDC and want to exchange it for ETH, he would get only 0.5 $ETH.

Here is how:
Considering $ETH/$USDC pool with 2,000 $USDC and 1 $ETH in the reserves, for our constant product funtion, x = 2,000, y = 1, and x * y = k(constant) = 2,000. The instantaneous price of this AMM is 2,000 / 1 = 2,000 USDC per ETH.

After the trade x will be equal to 4,000 thus we get y = 2,000/4,000 = 0.5, the difference in y is what the traders receive.

The information that Joe earlier received about the $ETH price rally doesn’t look good enough after getting $ETH at the price of $4,000.

Due to a huge order, Joe faced extreme price impact and the AMM saved its pool from getting fully swapped into a single asset (a trait of constant product function market makers).

In traditional finance, if an investor has to buy a huge amount of shares of a certain company they would prefer to buy those over an interval of time. They are likely to approach a broker who would provide this service (buying small quantities of shares over a course of duration).

Joe could have done the same thing and segmented his order into smaller orders to face a lower price impact while trading 2000 $USDC for $ETH.

This is efficient because when smaller orders are placed, there is obviously less price impact and the pool is rebalanced by the arbitrageurs. Thus it is possible to execute all the small orders at nearly the same price. The trader may need to wait for the pool to get balanced before placing subsequent orders.

In the above scenario fees to execute the transactions will increase more than the trade value if too many orders are made. In the case where the trade is only broken into a few orders, there lies a chance that the trader still faces a considerable amount of price impact and risk of sandwich attack as well.

The Time-Weighted Average Market Maker (TWAMM) provides the on-chain equivalent of the broker that was discussed earlier referencing the traditional financial system.

Basically, TWAMM can be considered as an AMM that can provide a service to execute large orders at a fair price with lower transaction fees (gas fees).

The TWAMM has specialized logic for order splitting and traders can submit long-term orders to sell a fixed amount of one of the assets over a fixed number of blocks — say, an order to sell 100 ETH over the next 2,000 blocks.

The TWAMM breaks these long-term orders into infinitely many infinitely small virtual sub-orders, which are executed in the AMM(remember TWAMM is a kind of AMM) at an even rate over time.

Arbitrageurs will ensure better prices and good execution for long-term orders.

TWAMM: Underlying mechanics

Alice wants to buy $100mm worth of $ETH over the next 2,000 blocks (8 hours).
Bob wants to sell 500 $ETH for $USDC over the next 5,000 blocks, or 0.1 $ETH per block.
Charlie wants to sell 100 $ETH for $USDC over the next 2,000 blocks, or 0.05 $ETH per block.

Similar orders are grouped and are executed in the AMM; x quantity per block basis.

For example, Bob’s and Charlie’s orders will be grouped together in a pool as 1.5 $ETH per block.

Every block for the 2,000 blocks, the TWAMM has to buy $50,000 worth of $ETH on behalf of Alice and sell 0.15 $ETH for $USDC on behalf of the $ETH selling pool. The TWAMM then takes turns executing these virtual/sub orders from each pool (selling/buying)in the AMM to keep the price smooth.

After block 2,000, Alice’s and Charlie’s orders will be completely filled. Bob’s order to sell $ETH will operate for the next 3,000 blocks, at a rate of 0.1 $ETH per block.

Because Alice is buying much more $ETH than the $ETH pool is selling, the $ETH price would rise in the AMM and arbitragers would balance it.

For gas efficiency, TWAMM uses lazy evaluation: computing the effect of sub-order trades only when it is necessary to determine the outcome of an interaction. Whenever a user interacts with the TWAM, it retroactively calculates the effect of all the sub-order trades that took place since the last interaction.

Let there be an interaction at block 1,500.

In our example for 2,000 blocks, all three orders were going to get executed at a certain rate.

But due to the interaction noted at 1,500 blocks, we need to calculate the current positions of each order. Thus we have to do three separate trade calculations in order to find out what happened: one for each order until block 1,500.

If there had been orders expiring (order expiring is considered as an interaction here) every block for the past 1,000 blocks, this would mean the TWAMM would have to process the trades in each block, ultimately ruining gas efficiency.

This could be solved by limiting the options to choose the order duration (e.g. expire every 250 blocks). Thus orders expiring only happens at fixed intervals providing gas efficiency. It could even be made more efficient by fixating the time when order inflow is noticed.

Thank you for being here.

You can provide the same value by sharing this article with your circle.

You could even contribute/support these articles by owning one ✌.

Thank you for being here.

You can provide the same value by sharing this article with your circle.

You could even contribute/support these articles by owning one ✌.