Happy New Year 🎊🎉! What a great month to be focused on developing TWAMM with all the market choppiness and hacks😅.
We’ve created an end-to-end TWAMM simulator featuring historical market data and transactions, arbitrage bots, simulated long-term swaps, and a Uniswap style UX to explore how TWAMM functions in a variety of real-world scenarios.
The block diagram below illustrates our interactive simulator’s high-level architecture. The simulator will help us battle test TWAMM with repeatable real-world scenarios to quickly identify and solve technical issues like numerical stability, gas costs, denial of service attacks, and other challenges.
Some key details in the system diagram above:
The original TWAMM paper published on the Paradigm blog contains considerable nuance. One area that has had very little discussion online to date is in the following section:
Front-ends plugged into the TWAMM will be able to account for virtual trades that have not yet been represented on-chain by keeping track of the current block number and doing the TWAMM calculation themselves.
The current public Solidity contract for TWAMM will not support offline quoting as it is written, however, this functionality is quite important. It’s important to understand that if the TWAMM contract has not undergone any transaction that results in the execution of virtual trades, the reserve amounts stored in the state may be incorrect. Specifically when the contract is executing active long-term swaps.
One solution to get the reserves would be to execute a call to the contract’s executeVirtualOrders method—however, because this method modifies the contract state it costs gas (562K WEI!). A lot of gas—too much for users who simply want a quote for what they will receive in either a long-term or short-term swap in a pool. This table shows the simulated gas used by the aforementioned Solidity contract for the executeVirtualOrders method:
To address this we developed an offline reserve calculation algorithm that can be used to provide quotes to users of a TWAMM pool. The algorithm only reads contract state and thus does not incur a gas usage fee.
It’s important that the algorithm be accurate to the network TWAMM contract, faithfully replicating the EVM’s fixed precision arithmetic or quotes would be inaccurate. To facilitate accuracy, we replicated the exact TWAMM computation used by the contract in Typescript using Ethers BigNumber library.
Comparisons to the contract reserves after a call to executeVirtualOrders showed that our algorithm generated a perfect match to the contract’s values.
One important note about the algorithm is that it must read the contract state multiple times in a single execution. Initially to fetch some initial values from contract state and then continuously from the last execution block up to the current block to factor order expiries into the reserve computation.
The next development iteration will primarily be focused on quantifying, comparing, and optimizing gas usage of the TWAMM contract. Additionally, an exponential backoff of the ability to place long-term swaps in an effort to prevent denial of service attacks is also scheduled for development.
Beyond these two objectives, minor work on extending the simulator’s capabilities and exploring the limitations of TWAMM will also continue.
The diagram below illustrates the multitude of avenues for the application, development, and integration of TWAMM technology in the future. These concepts and others which are currently under development will be discussed in future posts after the fundamental AMM functionality is deployed to mainnet.
As a parting thought consider the scenario from recent DeFi liquidations outlined in the Tweet below. Specifically, how might price impact in this situation be alleviated with TWAMM aiding protocols movement in and out of large positions in a reasonable timeframe?