Happy holidays folks🎄, here’s what we’ve been working on the past few weeks in TWAMM land.

New Contract Features

• We've refactored the solidity contract to execute virtual orders to a specified block number, as discussed with Frankie. Use cases with blocks specified in the future and past are handled (the time-travel edge cases).
• We've introduced a 0.03% fee for long-term trades. This includes a fee for long-term order cancellation, applied to the proceeds.
• Both these additions will be undergoing more extensive testing going forward and we're considering making the long-term trade fee to a contract parameter determined at pool creation.

Sales Rate Fixed Precision Limitations

We've become more familiar with the fixed precision limitations of the TWAMM implementation with respect to sales rates and LT (long-term) trade parameters.

• Isolated testing of TWAMM using our port of Frankie's testbench to Hardhat revealed that one of the test cases was deviating from the expected final reserve more than 1% off the expected value.
• We determined that when the swap amount is too small, or the number of block intervals is too large, the loss of precision in the sales rate results in a significant loss (we say loss instead of slippage because this is not from traversing to a disadvantaged region of the bonding curve).
• The following diagram shows the percent lost and the percent error between an idealized constant product swap for varying amounts of Token A swapped in a pool with one billion of token A and token B (the pool is reset to the initial one billion of each token for each swap):

• Exploring the parameter space further, we observed that changing the LT swaps to be 100 intervals of 10 blocks, up from 10 intervals of 10 blocks, the fixed precision error is shifted an order of magnitude as expected:

• The formula for sales rate illustrates the reason for this shift to the right.

sales_rate ~= swap_amount / ((number_of_intervals + 1) * blocks_per_interval)

• This formula is computed with integer arithmetic and the error improves the more the swap_amount exceeds the value of the denominator. The closer the swap_amount gets to the denominator in value, the closer the sales_rate gets to becoming zero, an error condition. The sales rate error is inversely proportional to the number of intervals and blocks per interval.
• For production, we propose documenting this scenario and also releasing template code/application examples for DEXs/Exchanges that would allow them to identify if a user's swap would fall into a region with an undesirable sales rate due to precision effects.

Simple Arbitrage

TWAMM's ability to perform large trades while minimizing slippage in low liquidity pools is one of its notable capabilities. To evidence this, we've started constructing simple arbitrage tests and comparing them to the values expected from a traditional constant product AMM.

For example, in a pool that starts out with 1B of each token, we're observing a 100M token trade is possible in the course of 100 blocks with only 1.52% slippage loss instead of the 9.36% slippage loss expected from a simple constant product AMM trade because of the benefits of arbitrageurs with TWAMM.

An arbitrage bot was added to the system; the bot in this case makes a trade every time the price ratio is less than 0.98 to restore 1B token parity. The figure below shows the constant buy rate of token A and the declining sell rate of token B due to slippage from traversing the bonding curve. In the figure, we observe the sell rate return to the sweet spot whenever the arbitrage bot takes action.

The arbitrage test final output is shown below. CP error is the difference between the realized value from TWAMM and an equivalent idealized constant product AMM trade.

TWAMM INFO
Out A 0
Out B 0
End A 1000815872
End B 999482861
Writing csv ...
done
addr1 (0x70997970C51812dc3A010C7d01b50e0d17dc79C8):
  expect 90636363.63636361 of tokenB according to const. prod.
  bought 98476089 of tokenB with 100000000 of tokenA
  if A == B, addr1 lost 1523911 (1.523911) %
  cp error = -8.649646840521594%
        ✓ Arb stabilizes the transaction

Reducing Gas Usage

Previously we instrumented the original test suite ported from Frankie's repository to determine a top-level figure for gas used.

While useful for identifying costly operations and prioritizing gas reduction efforts, it was important to be able to get a further breakdown of a top-level TWAMM function's internal gas usage—i.e. the individual instructions within the function and the functions it calls.

This was accomplished by integrating our Hardhat project with Tenderly's debugging and profiling technologies. Here's an example breakdown of the gas used inside a call to LongTermOrders.sol::executeVirtualTradesAndOrderExpiries made from a top-level TWAMM call to executeVirtualOrdersToBlock in the aforementioned arbitrage test:

Another benefit of Tenderly's tools is that we're now able to step through the contract Solidity code to better examine the operation of the TWAMM contract in our testing.

Going Forward

After the holiday break, we're looking at the exponential back-off modification to the contract suggested by Dan and more aggressively understanding gas usage and ways to reduce it, in addition to continuing to develop our test suite. Another near-term item is the development of the code templates for offline analysis of a TWAMM pool that DEX's, Front Ends, & Exchanges can reference. These templates may also require modified access to the LongTermTrades and OrderPool objects in the TWAMM contract so that reserves can be calculated offline without gas fees. A quarterly roadmap is in the works, which we're hoping to publicize in the next update.