🕰️Order Block Interval (OBI)

Order Block Interval (OBI) is an explicit parameter on the reference Solidity implementation in [2]. It specifies the number of blocks between the execution of virtual orders and explicitly limits temporal resolution for specifying trades. The temporal resolution limitation arises because the length of an LT-Swap is expressed in integer multiples of the OBI. Thus if the OBI was 10,000 and a user desired an LT-Swap expiring in 7,000 blocks, it would not be possible; the earliest possible expiry would be approximately 10,000 blocks from swap initiation.

Virtual Order Execution Iterations

Computing the result of the closed-form mathematical formula described in [1] can alternately be described as performing a virtual order execution iteration, where each iteration occurs at a specific block. The block where each iteration occurs is controlled by the OBI and when the pool was deployed. Importantly, OBI will be shown to significantly reduce gas usage by reducing the number of iterations that the closed-form mathematical formula needs to be computed for periods of inactivity during active LT swaps.

If no TWAMM operations necessitating virtual order execution occur for an arbitrary number of blocks, a.k.a. blocks of inactivity, the next TWAMM operation requiring virtual order execution incurs the cost of executing all the virtual orders since the last such operation. The number of virtual order execution iterations incurred for a given block number in such a scenario can be calculated with the following formula:

Equation 1: Virtual Order Execution Iterations

Where:
  VOE Iterations = Virtual Order Execution Iterations
  BN = Block Number
  LVOB = Last Virtual Order Block
  OBI = Order Block Interval 

The inverse relationship in equation (1) between iterations and OBI suggests that for pairs with significant inactivity, larger order block intervals may be appropriate to reduce gas usage. To illustrate this relationship, consider a TWAMM pair last updated at block 1000, the Last Virtual Order Block (LVOB), with a new TWAMM operation requiring virtual order execution issued at the current block, BN, 1201. Equation 1 can be used to plot the number of iterations against the OBI for this 201 block inactivity scenario:

Figure 1.0: Virtual Order Execution Iterations vs. Order Block Interval for 201 Block Inactivity Scenario

Measuring Gas Usage

Deploying the reference Solidity contract from [2] on Hardhat’s EVM permits the measurement of gas usage for the top-level contract methods.

To measure the gas used in the 201 block inactivity scenario described above, a single LT-swap transaction is issued to the deployed TWAMM pool. Then 201 blocks are mined with no other transactions against the pool. Finally, an explicit call to the pool contracts executes the virtual orders method is made. The transaction receipt from the EVM reports the gas used by the execute virtual orders transaction.

Note:

1. The contract used for measurement herein is based on the reference Solidity contract of [2] with minor modifications (introduction of fees and other changes that will be detailed in a future report).

2. The test has been scripted to issue the initial LT-swap for the same number of blocks for each of the different block intervals—this keeps the sales rate as close as possible for each value of OBI tested to reduce any potential arithmetic/computation-induced gas measurement differences.

Figure 2 below shows the measured gas to execute virtual orders in a sweep of OBI values from 1 to 100 for the 201 block inactivity scenario during a single active LT-swap:

Figure 2.0 Execute Virtual Orders Gas Used vs. Order Block Interval for a Single LT-Swap After 201 Blocks of Inactivity.

The results of Figure 2.0 clearly indicate that choosing larger block intervals offers a significant reduction in gas usage for all transactions.

The primary downside to choosing larger values of OBI is the previously mentioned reduction in temporal resolution for LT-swap duration and expiry. Another effect of larger OBI values, beyond the scope of this discussion, is that the minimum amount sold in a swap transaction must be increased to avoid losses due to finite precision arithmetic errors—this effect is illustrated in [3] (see figures “Loss & Constant Product Error for Varying Swap Amounts” and “Loss for Varying Swap Amounts”).

References

1. Paradigm, “TWAMM”, July 28, 2021, Online. Available: www.paradigm.xyz/2021/07/twamm.

2. TWAMM (2021). Online. Available: github.com/FrankieIsLost/TWAMM.

3. 0x70626a.eth, “TWAMM Research: December 2021”, December 22, 2021. Online. Available: mirror.xyz/0x70626a.eth/SIpA5Z4M6VYqCfvSKpTpRFw6bftE2ghi7fc7TA4c3LE.