Can LT Swaps stay active when the Ethereum blockchain network is dead?
The reference design in  expresses order intervals in blocks referred to as Order Block Intervals (OBI). The FRAX TWAMM implementation  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  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  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  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  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.