Comment on page
Long-Term (LT) Swap Scenarios
Another important factor in TWAMM’s gas usage is the LT-Swap scenario. Real-world TWAMM use would include the situation where there are one or more active LT swaps, offset, and also occurring in opposite directions.
Consider a TWAMM pool consisting of Token A and Token B. Direction, in this case, refers to a swap from Token A to Token B—the opposite direction would be from Token B to Token A. Figure 3.0 below illustrates some of the important possible LT swap scenarios:
Figure 3.0: Different TWAMM Long-Term (LT) Swap Concurrency Scenarios. In scenarios 3-5, any period where there are overlapping LT Swaps of a different direction represents the maximum gas usage of the contract. Scenario 6 is negligibly different in gas usage from scenario 2, the difference arises from having to manage more contract expiries in scenario 6. Scenario 1, No Swap, represents the minimum gas use of the contract in the presence of inactivity.
The first scenario in figure 3.0 above represents minimal gas usage in the presence of inactivity because the contract will not perform CPAMM or TWAMM arithmetic, nor will it be modifying a significant amount of the blockchain state. Scenario 2, represents the next best possible scenario because despite requiring more state updates than scenario 1, the required arithmetic is still inexpensive. Specifically, the contract is performing the less expensive CPAMM arithmetic to execute virtual orders in this scenario. Although unintuitive on inspection, scenario 6 is similar in gas usage to scenario 2, with the exception that there are increased state updates to handle LT-swap expiration (An attack based on expirations is described in  and will be addressed in a forthcoming report). The arithmetic performed in scenario 6 is still basic CPAMM and isn’t more expensive than scenario 2 because the sales rate of the 4 concurrent LT-swaps is aggregated into a single rate using the technique described in .
Scenarios 3-5 represent the worst-case gas usage because, in addition to managing additional LT-swap expirations, the reserve update for each virtual order execution is the more complex, gas-consuming TWAMM arithmetic defined by the following equations, explained in detail in  and :
Given that the worst-case gas usage for the contract is scenarios 3-5 from figure 3.0, the experiment used to generate figure 2.0 can be modified to feature two opposing direction LT-swaps. Retaining the values of all other experiment parameters and re-using the same gas measuring procedure as before, the plot of gas usage for a block interval sweep when two opposing direction LT-swaps are active appears below in figure 4.0:
Figure 4.0 Execute Virtual Orders Gas Used vs. Order Block Interval for Two Concurrent Opposing LT-swaps after 201 Blocks of Inactivity. Note the considerable gas usage increase over a similar experiment with a single LT-swap from figure 2.0.
Figure 4.0 shows gas usage approaching 15 million for an OBI of 1—this is the target gas for an entire Ethereum block, post EIP-1559 (network demand can cause this to increase up to 30 million gas). Even at an OBI of 20, virtual order execution after 201 blocks of inactivity uses about 1 million gas.
Note: Hardhat users will recognize that the measurement methodology outlined previously would present challenges in producing figure 4.0, especially the ~15M gas measured for an OBI of 1. The main problem is that Hardhat uses the eth_estimateGas RPC call, which results in timeouts for larger gas measurements. To get around this issue, it’s possible to specify larger timeout delays in Hardhat configuration; 120,000ms proved sufficient in this case.
- 2.B. Batog, L. Boca, and N. Johnson, “Scalable Reward Distribution on the Ethereum Blockchain”, Online. Available: uploads-ssl.webflow.com/5ad71ffeb79acc67c8bcdaba/5ad8d1193a40977462982470_scalable-reward-distribution-paper.pdf.