UST lost its peg and caused $60 billion in retail losses 😵‍💫 causing far-reaching DeFi ecosystem damage. TWAMMs probably wouldn’t have stopped the de-pegging of UST, however, they could have mitigated the shock of large-scale asset movement, allowing liquidity to be added and removed gradually.

During such turbulent markets, most DEX’s were not able to handle the volume and OTC desks are inaccessible to most retail participants. The image below shows how liquidity was unavailable on DEXs, preventing traders from exiting their UST positions.

Even when markets are relatively calm, large trades for low float tokens are difficult to process via DEXs and aggregators because they are impaired by the constraint of completing the trade in one block. In the below $10M ETH <> OHM swap example, the best aggregator quote cause roughly 30% slippage, and ~$3M in losses; the FEI team will likely manually split the trade over an extended timeline to get a better fill.

https://twitter.com/JackLongarzo/status/1528052671613214720

We had some very insightful meetings with various market participants, primarily portfolio managers and protocols to get a better understanding of their product needs and issues with current market solutions -- OTC desks.

Here are some key points of feedback we gathered from liquid portfolio managers:

• Liquidity matters more than privacy. Although privacy is a concern, they are used to creating fresh wallets for purchasing assets.

• Range orders or fully automated orders are the killer feature for TWAMM. Below is an example order:

Buy 10% of float of a small cap token over the next 3 months if price is in specified range

Also, a major pain point when trading low float tokens via OTC desks is the adversarial nature of the trade, long quote time delays, and high fees charged.

https://twitter.com/sherlock_hodles/status/1532449128365580288

Speaking of maintaining pegs, the Olympus team reached out to us to discuss how TWAMM can help them perform market-making operations while maintaining the price of OHM.

The above figure illustrates how Olympus plans to maintain a soft peg by using its treasury to help stabilize the price of OHM. Olympus needs the price of OHM to be bounded such that bonds can be accurately priced, improving protocol capital efficiency.

We also met with the broader Maker Protocol Engineering team to discuss potentially using our TWAMM implementation -- thanks to Kurt Barry 🙌 for arranging the meeting.

https://forum.makerdao.com/t/signal-request-deploy-a-trial-permissionless-open-market-operation-resurrect-the-burn/15381/25

The DSSKiln tool built by the Maker team buys a given asset at a set interval using Uniswap V3. It relies on a network of Keepers to initiate intermediate buy orders and is gas expensive because each suborder is settled on-chain. TWAMM can automate this process, providing a better fill on these large orders without relying on keepers for less gas.

Another interesting point that was brought up in the discussion is the advantage of using block-based intervals over time-based intervals. As you can see in the below image, in the off-chance Ethereum goes down, a block-based interval TWAMM pool halts trading preventing asset prices from skewing at restart.

In both discussions with Olympus DAO & MakerDAO, the protocols cited a need for a TWAMM pool native oracle system to track asset prices. This is a huge pain point that Maker has been exploring a solution for because they’re unable to onboard small-cap tokens that have insufficient DAI liquidity pairing. See the myriad of tokens requesting onboarding every month to the MakerDAO platform:

https://forum.makerdao.com/c/collateral-onboarding

We were able to successfully prototype TWAMM specific virtual order features in a Balancer custom pool. The below image shows how we used the userData field to achieve TWAMM specific functionality through parameter values like long-term swap, withdraw, cancel, intervals, orderId, etc.

In the next detailed technical write-up, we will explore TWAMM specific implementation details and performance when integrated with Balancer Vault.

In our push to thoroughly research attack vectors for TWAMM, we published our findings from interesting theoretical attacks like Service Denials, Order Bombing, and Zombie Swaps. You can read the detailed analysis of these attacks' performance degradation and gas costs in the below post.

https://mirror.xyz/0slippage.eth/AMvO7nUgpoP9Ue3hEm7iuA9V1d97pSfcbe1bJdo1lbo

Going forward, we will be optimizing and completing a thorough numerical analysis of our Balancer TWAMM implementation. If we continue to hit our milestones, we should have an unaudited V1 on mainnet in the next two months -- soon TM!

UST lost its peg and caused $60 billion in retail losses 😵‍💫 causing far-reaching DeFi ecosystem damage. TWAMMs probably wouldn’t have stopped the de-pegging of UST, however, they could have mitigated the shock of large-scale asset movement, allowing liquidity to be added and removed gradually.

During such turbulent markets, most DEX’s were not able to handle the volume and OTC desks are inaccessible to most retail participants. The image below shows how liquidity was unavailable on DEXs, preventing traders from exiting their UST positions.

Even when markets are relatively calm, large trades for low float tokens are difficult to process via DEXs and aggregators because they are impaired by the constraint of completing the trade in one block. In the below $10M ETH <> OHM swap example, the best aggregator quote cause roughly 30% slippage, and ~$3M in losses; the FEI team will likely manually split the trade over an extended timeline to get a better fill.

https://twitter.com/JackLongarzo/status/1528052671613214720

We had some very insightful meetings with various market participants, primarily portfolio managers and protocols to get a better understanding of their product needs and issues with current market solutions -- OTC desks.

Here are some key points of feedback we gathered from liquid portfolio managers:

• Liquidity matters more than privacy. Although privacy is a concern, they are used to creating fresh wallets for purchasing assets.

• Range orders or fully automated orders are the killer feature for TWAMM. Below is an example order:

Buy 10% of float of a small cap token over the next 3 months if price is in specified range

Also, a major pain point when trading low float tokens via OTC desks is the adversarial nature of the trade, long quote time delays, and high fees charged.

https://twitter.com/sherlock_hodles/status/1532449128365580288

Speaking of maintaining pegs, the Olympus team reached out to us to discuss how TWAMM can help them perform market-making operations while maintaining the price of OHM.

The above figure illustrates how Olympus plans to maintain a soft peg by using its treasury to help stabilize the price of OHM. Olympus needs the price of OHM to be bounded such that bonds can be accurately priced, improving protocol capital efficiency.

We also met with the broader Maker Protocol Engineering team to discuss potentially using our TWAMM implementation -- thanks to Kurt Barry 🙌 for arranging the meeting.

https://forum.makerdao.com/t/signal-request-deploy-a-trial-permissionless-open-market-operation-resurrect-the-burn/15381/25

The DSSKiln tool built by the Maker team buys a given asset at a set interval using Uniswap V3. It relies on a network of Keepers to initiate intermediate buy orders and is gas expensive because each suborder is settled on-chain. TWAMM can automate this process, providing a better fill on these large orders without relying on keepers for less gas.

Another interesting point that was brought up in the discussion is the advantage of using block-based intervals over time-based intervals. As you can see in the below image, in the off-chance Ethereum goes down, a block-based interval TWAMM pool halts trading preventing asset prices from skewing at restart.

In both discussions with Olympus DAO & MakerDAO, the protocols cited a need for a TWAMM pool native oracle system to track asset prices. This is a huge pain point that Maker has been exploring a solution for because they’re unable to onboard small-cap tokens that have insufficient DAI liquidity pairing. See the myriad of tokens requesting onboarding every month to the MakerDAO platform:

https://forum.makerdao.com/c/collateral-onboarding

We were able to successfully prototype TWAMM specific virtual order features in a Balancer custom pool. The below image shows how we used the userData field to achieve TWAMM specific functionality through parameter values like long-term swap, withdraw, cancel, intervals, orderId, etc.

In the next detailed technical write-up, we will explore TWAMM specific implementation details and performance when integrated with Balancer Vault.

In our push to thoroughly research attack vectors for TWAMM, we published our findings from interesting theoretical attacks like Service Denials, Order Bombing, and Zombie Swaps. You can read the detailed analysis of these attacks' performance degradation and gas costs in the below post.

https://mirror.xyz/0slippage.eth/AMvO7nUgpoP9Ue3hEm7iuA9V1d97pSfcbe1bJdo1lbo

Going forward, we will be optimizing and completing a thorough numerical analysis of our Balancer TWAMM implementation. If we continue to hit our milestones, we should have an unaudited V1 on mainnet in the next two months -- soon TM!