Scenarios for failing transactions

[brozorec]

How to deal with failed transactions on the destination chain? A failed transaction couldn't be executed, and the bridged funds (if any) were stuck on Fuji's or Connext's side.

Causes on Connext's side

1. Slippage as described in ConnextRouter bridging slippage #253
2. Router doesn't handle the bridged funds properly (no try/catch) and they stay stuck in Connext contract (ref)

Causes on Fuji's side

1. Wrong nonce (we try to execute transactions in a reversed order somehow)

• sending tx from two chains to the same destination chain
• sending two txns to the same dest chain

3. Non-respected slippage on the SWAP action
4. Close to liquidation borrow, the transaction arrives later, after a sudden price change. That makes the transaction revert.
5. When closing a position or doing a "maxed" operation, some interest could be accrued, from the moment the tx was initiated until the moment it was executed.
6. [Non-SC] We'll sponsor the relayer fees, so we need to rely on an external party's infra (Planning to use OZ Defender). What if it fails for some reason? That will lead to a queue of transactions waiting to be executed on the dest chain (the cases from 1. can also occur here).

[0xdcota]

Adding more:

Causes on Fuji's side

7. Wrongly encoded args in xReceive() calldata. Examples of this case will be: withdrawals out of sequence with no permits or prior allowance, passing address(0) for calls like deposit, withdraw, borrow, payback, wrong owner or receiver.

[brozorec]

A potential inspiration to address the first case (1. Wrong nonce) can come from https://github.com/Uniswap/permit2 which implements "Non-monotonic nonces". More research is needed here.