Happy holidays folks🎄, here’s what we’ve been working on the past few weeks in TWAMM land.
New Contract Features
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.
sales_rate ~= swap_amount / ((number_of_intervals + 1) * blocks_per_interval)
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.