Removing Collaborative Cancellations

[LayneHaber]

Summary

Right now if a router cancels a payment pre-expiry on the sender side (i.e. they can no longer serve those prices, or user cancelled receiver), they are exposed to the gas costs. This means any collaboratively cancelled transaction is a net loss for the router. Additionally, the expiry ranges are set as immutable without any way to update them based on production data. Instead, collaborative cancels should be removed and the expiries should be much shorter, and tunable.

Motivation

At present routers face irrecoverable costs to cancel a transaction, even if they are doing everything correctly. Imagine a router that submits a bid, but is not able to fulfill it until the pricing has expired (i.e. now the slippage would be out of the bounds set in the bid). The correct thing for the router to do is to cancel the user's payment pre-expiry, but this will cost gas they do not get reimbursed or take fees for.

Proposed Solution

The best solution here would be to decrease the minimum expiry on the sender side and remove collaborative (pre-expiry) cancellations completely. The main purpose behind collaborative cancellations was to release funds in a reasonable time. If we are able to reduce the minimum expiry, the UX can still be preserved without the routers paying funds for cancellations. An additional consideration would be to allow for fulfillment post-expiry rather than only allowing cancellations. This way, transfers with non-malicious users would be able to be fulfilled on the sending chain even after the expiry.

Additionally, as we move towards auctionless routing users will no longer need to wait for a given router and the chances of a transaction being properly prepared increase.

To implement this:

contract TransactionManager {
	/**
    * @dev Minimum timeout (will be the lowest on the receiving chain)
    */
  uint256 public minTimeout = 1 days; // 24 hours

  /**
    * @dev Maximum timeout (will be the highest on the sending chain)
    */
  uint256 public maxTimeout = 30 days; // 720 hours

  function setMinTimeout(uint256 timeout) external override onlyOwner {
    require(timeout < maxTimeout, "Must be lt max");
    minTimeout = timeout;
  }

  function setMaxTimeout(uint256 timeout) external override onlyOwner {
    require(timeout > minTimeout, "Must be gt min");
    maxTimeout = timeout;
  }

  function cancel(CancelArgs calldata args) {
    // Always enforce the transfer has expired
  }
}

Tests

The following should be implemented:

it("cancel should fail when transfer not expired", () => { ... })
it("cancel should work when transfer expired", () => { ... })
it("setMinExpiry should fail when not called by owner", () => { ... })
it("setMaxExpiry should fail when not called by owner", () => { ... })
it("setMinExpiry should work", () => { ... })
it("setMaxExpiry should work", () => { ... })
it("fulfill should work post-expiry IFF transfer has not been cancelled", () => { ... })

Outstanding Questions

• What should the new defaults be?

Tasks

• Make minTimeout configurable
• Make maxTimeout configurable
• Remove pre-expiry handlers in cancel
• Enforce transfer is expired in cancel
• Relax expiry enforcement in fulfill

[sanchaymittal]

• How do we make sure the router fulfill is happening timely? Considering Rpc breakdowns or some other issue pops up, the timeline will be short to expect the router's response.

• Also need to bump up the router's fees threshold offChain.

[ArjunBhuptani]

How do we make sure the router fulfill is happening timely? Considering Rpc breakdowns or some other issue pops up, the timeline will be short to expect the router's response.

With the new changes, we could allow anyone to call fulfill on behalf of a router. This means we can create a failsafe system to fulfill on behalf of routers within X blocks of expiry if they have not already done it themselves.

[jakekidd]

@ArjunBhuptani can anyone call fulfill on behalf of a router? If so, that can be frontrun, right? Also creates a situation where routers will race each other to complete each others' fulfills, right?

[LayneHaber]

Sure, but if it's assigned to a router then why do they care if they race? We shouldn't optimize for being the best relayer network, but the best crosschain network. Plus, we can have a single server that is solely responsible for submitting txs that isn't a router at all so they dont race each other.

But yes, relayer networks are susceptible to being frontrun (and we've already seen this on Gelato!)

[ArjunBhuptani]

@ArjunBhuptani can anyone call fulfill on behalf of a router? If so, that can be frontrun, right? Also creates a situation where routers will race each other to complete each others' fulfills, right?

As long as it's not free to frontrun (i.e. we're not providing an arbitrarily high gas fee reimbursement like described in #748), frontrunning is ok. In general, frontrunning is unavoidable - we just need to make sure we don't make it free.

[base0010]

Really think the UX of anyone can call fulfill makes alot of sense here.

[LayneHaber]

No longer relevant in the new designs