Hi all 🤙 , another great month of TWAMM R&D. We have continued to engage with potential customers and partners to build a strong ecosystem around our product. After our conversation with the Syndicate DAO team, we are excited to have them come on board as an integration partner.

One of the key components of TWAMM is the underlying AMM and the unique advantages each existing AMM provides like Uniswap V3 concentrated liquidity, Balancer pool configurations, and Curve stable swap. We want to build a configurable product where different underlying AMMs can be selected based on preferences like trade volumes, type of pool assets, gas efficiency, and incentive structures.

The first underlying AMM we plan on supporting will be Balancer as it enables us to deploy to mainnet fastest; in addition to other benefits like liquidity and features perfect for TWAMM like batch/flash swaps -- see tweet below. Furthermore, we have received a grant from Balancer Grants DAO to develop TWAMM on their Vaults V2 architecture via a custom pool.

https://twitter.com/balancerlabs/status/1509909183738650625

Finally, we are in the process of finalizing a grant from KeeperDAO to investigate the merits of first right arbitrage and how it’ll be beneficial for LPs -- see tweet below. As the majority of the trades on the underlying AMM will be arbitrageurs correcting asset prices, we believe that this partnership will provide better MEV protection for passive LPs.

https://twitter.com/hasufl/status/1504524010717077504

This past month we have been focused on attack vectors, measuring and optimizing the gas usage of TWAMM at different levels: algorithm, numerical containers, and underlying AMM. We built a benchmarking tool to help us get accurate measurements of the optimizations and numerical stability based on our changes to the architecture.

Disclaimer: these figures were obtained from integrating the FRAX approximation in the FrankieIsLost reference TWAMM design and are not indicative of the performance of the FRAX TWAMM contract. This work illustrates that numerical considerations may be important in applying approximations. A forthcoming comprehensive comparison between the actual FRAX contract and our TWAMM implementation in a variety of scenarios will be a more reasonable indicator of numerical performance.

We composed a test that issued an attack of 20 LT swaps of differing tiny amounts (2 at a time from Token A->B and vice-versa, the worst-case gas usage for TWAMM, contiguously on block-interval boundaries--block interval=10). Prior to launching the attack, a real LT-swap trade is issued. After the attack, the pool is inactive to accumulate 18 intervals (180 blocks) of inactivity to process executing virtual orders.

The attacks expire contiguously on block interval boundaries in the period of inactivity. When the gas usage of the OrderPool expiry handler (updateStateFromBlockExpiry) is examined, there’s a single 6k bump in gas usage once. When we look at the entire transaction cost, for the attack and control scenarios, the gas usage is negligible.

In order to stress-test the various TWAMM optimizations we’ve done so far and plan to do, we built a repeatable benchmark generator to simulate market conditions with configurable gaussian event distribution. Our highly modular tool enables us to generate repeatable event test vectors, allowing details as high as overall test length and as low as the standard deviation of swap amounts to be configured.

We did a deep dive into the TWAMM equations from the original paper and described how we believe Frax arrived at their approximation. Additionally, we explained the tradeoffs where the approximations perform in line, better or worse than the gas-intensive methods based on varying market conditions.

You can see a much more detailed post about the TWAMM algorithm optimization & approximation analysis here:

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

After our deep dive into the TWAMM algorithm and operational parameters, we have found a novel optimization using different storage and numerical optimizations that could shave an additional 30% or more in gas usage.

Hi all 🤙 , another great month of TWAMM R&D. We have continued to engage with potential customers and partners to build a strong ecosystem around our product. After our conversation with the Syndicate DAO team, we are excited to have them come on board as an integration partner.

One of the key components of TWAMM is the underlying AMM and the unique advantages each existing AMM provides like Uniswap V3 concentrated liquidity, Balancer pool configurations, and Curve stable swap. We want to build a configurable product where different underlying AMMs can be selected based on preferences like trade volumes, type of pool assets, gas efficiency, and incentive structures.

The first underlying AMM we plan on supporting will be Balancer as it enables us to deploy to mainnet fastest; in addition to other benefits like liquidity and features perfect for TWAMM like batch/flash swaps -- see tweet below. Furthermore, we have received a grant from Balancer Grants DAO to develop TWAMM on their Vaults V2 architecture via a custom pool.

https://twitter.com/balancerlabs/status/1509909183738650625

Finally, we are in the process of finalizing a grant from KeeperDAO to investigate the merits of first right arbitrage and how it’ll be beneficial for LPs -- see tweet below. As the majority of the trades on the underlying AMM will be arbitrageurs correcting asset prices, we believe that this partnership will provide better MEV protection for passive LPs.

https://twitter.com/hasufl/status/1504524010717077504

This past month we have been focused on attack vectors, measuring and optimizing the gas usage of TWAMM at different levels: algorithm, numerical containers, and underlying AMM. We built a benchmarking tool to help us get accurate measurements of the optimizations and numerical stability based on our changes to the architecture.

Disclaimer: these figures were obtained from integrating the FRAX approximation in the FrankieIsLost reference TWAMM design and are not indicative of the performance of the FRAX TWAMM contract. This work illustrates that numerical considerations may be important in applying approximations. A forthcoming comprehensive comparison between the actual FRAX contract and our TWAMM implementation in a variety of scenarios will be a more reasonable indicator of numerical performance.

We composed a test that issued an attack of 20 LT swaps of differing tiny amounts (2 at a time from Token A->B and vice-versa, the worst-case gas usage for TWAMM, contiguously on block-interval boundaries--block interval=10). Prior to launching the attack, a real LT-swap trade is issued. After the attack, the pool is inactive to accumulate 18 intervals (180 blocks) of inactivity to process executing virtual orders.

The attacks expire contiguously on block interval boundaries in the period of inactivity. When the gas usage of the OrderPool expiry handler (updateStateFromBlockExpiry) is examined, there’s a single 6k bump in gas usage once. When we look at the entire transaction cost, for the attack and control scenarios, the gas usage is negligible.

In order to stress-test the various TWAMM optimizations we’ve done so far and plan to do, we built a repeatable benchmark generator to simulate market conditions with configurable gaussian event distribution. Our highly modular tool enables us to generate repeatable event test vectors, allowing details as high as overall test length and as low as the standard deviation of swap amounts to be configured.

We did a deep dive into the TWAMM equations from the original paper and described how we believe Frax arrived at their approximation. Additionally, we explained the tradeoffs where the approximations perform in line, better or worse than the gas-intensive methods based on varying market conditions.

You can see a much more detailed post about the TWAMM algorithm optimization & approximation analysis here:

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

After our deep dive into the TWAMM algorithm and operational parameters, we have found a novel optimization using different storage and numerical optimizations that could shave an additional 30% or more in gas usage.