🧟The Living Dead

Can LT Swaps stay active when the Ethereum blockchain network is dead?

The reference design in [2] expresses order intervals in blocks referred to as Order Block Intervals (OBI). The FRAX TWAMM implementation [7] significantly differs, expressing order intervals in time, specifically fixed 3600 seconds (1 hour) intervals.

Order Time Interval (OTI)

Block-based and time-based intervals result in different TWAMM operations, regardless of whether or not the interval is fixed or configurable. One of the most important differences is how an LT Trade will behave in the event of a blockchain outage for the two different interval types.

Network Outage: The Zombie Swap

If the Ethereum blockchain were to suffer a total network outage, LT swaps in a time-based interval TWAMM pool would continue to trade. This is because despite the Ethereum blockchain stopping, time would not stop. The underlying code of the FRAX contract [7] is shown in Figure 7, where the virtual order loop of Figure 1 has been modified to use timestamps instead of block numbers.

Figure 7: FRAX TWAMM contract method executeVirtualOrdersUntilTimestamp showing loop iterations based on time, not blocks, underscoring continuation of swaps during an Ethereum blockchain network outage.

Upon network operation resuming, the first transaction issued to the TWAMM pool executing virtual orders would update all virtual trades for active virtual orders for the elapsed time interval since the start of the outage. For example in a 5-hour network outage, the FRAX TWAMM implementation would compute 5 intervals of virtual trade updates for active LT swaps when a transaction executing virtual orders is issued subsequent to the outage. This is illustrated in Figure 8, where block and time interval-based pools are shown, each with an active LT swap and a 5-hour network outage.

Figure 8: Block and time-based interval TWAMM pools, each with an active LT swap with a 5-hour network outage. Note the block-based pool resumes operation at block 515 whereas the time-based pool resumes operation 5 * 3600s = 18000s later, however, its LT swap never paused, potentially resulting in higher slippage.

The implication of the outage in the worst case is that the time-based pool LT swap would suffer increased slippage due to the inability of arbitrageurs to correct price shifts in the pool resulting from virtual trades continuing during a network outage. Slippage potential increases with the duration of the network outage. In practice, this would likely be inconsequential for pool assets only featured on the Ethereum blockchain--however, this is not the case for assets on other blockchains or synthetic assets and derivatives (i.e. wrapped Bitcoin).

Conversely, a pool using block-based order intervals need not suffer this issue, depending on how the Ethereum blockchain resumes operation after an outage. If the blockchain starts at the next block number after the outage occurred, then no block intervals would have transpired. No block intervals transpiring means that no virtual trades will have occurred. Only if the block number is advanced multiple blocks after the block number of the blockchain outage would the behavior of the block-based interval TWAMM pool mimic the time-based interval pool in preventing arbitrage and continuing virtual trades.

Benefits of Time-Based Intervals

Beyond the intuitive nature of time-based intervals, other benefits of adopting a time-based interval include the:

• The TWAMM pool can participate across blockchains, where blocks differ in duration and elapsed time remains uniformly applicable.

• Tracking time is amenable to concentrated liquidity TWAMM implementations (see [8] for concentrated liquidity’s use of timestamps).

• Potentially reduced gas use. Choosing a 1-hour time interval equates to approximately 257 blocks and large block intervals were shown in [1] to increase contract gas efficiency.

  • The tradeoff is reduced resolution for order expiry and increased minimum LT swap duration.

• Other features requiring timestamps benefit from implementation and shared capture of moments in time, for instance, the Time-Weighted Average Price (TWAP) oracle described in [8] that no longer requires sampling TWAP value and recording the associated sample time for later use.

The downside of Time-Based Intervals

Apart from the earlier discussion on the potential for increased slippage in the event of a network outage, increased contract complexity, and possibly gas usage related to implementation details, any downsides to using time-based intervals in TWAMM pools are unknown at this juncture.

References

1. “Time Weighted Average Market Maker Operational Parameters vs. Gas Usage Analysis”, March 2022. Online. Available: https://mirror.xyz/0slippage.eth/5zKJW4Zx9zYHpB4jNln16HuU8d8EtawmA17usNfIje4.

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

3. Paradigm, “TWAMM”, May 20, 2021, Online. Available: https://www.paradigm.xyz/2021/07/twamm.

4. B. Batog, L. Boca, and N. Johnson, “Scalable Reward Distribution on the Ethereum Blockchain”, Online. Available: https://uploads-ssl.webflow.com/5ad71ffeb79acc67c8bcdaba/5ad8d1193a40977462982470_scalable-reward-distribution-paper.pdf.

5. “TWAMM Algorithm Optimization & Approximation Analysis“, April 2022. Online. Available: https://mirror.xyz/0slippage.eth/5zKJW4Zx9zYHpB4jNln16HuU8d8EtawmA17usNfIje4.

6. EVM Codes, “An interactive reference to Ethereum Virtual Machine Opcodes”, Online. Available https://www.evm.codes.

7. frax-solidity Uniswap_V2_TWAMM (2022). Online. Available: https://github.com/FraxFinance/frax-solidity/tree/master/src/hardhat/contracts/Uniswap_V2_TWAMM.

8. H. Adams, N. Zinsmeister, M. Salem, R. Keefer and D. Robinson, “Uniswap v3 Core”, March 2021. Online. Available: https://uniswap.org/whitepaper-v3.pdf.