Removing Collaborative Cancellations #758

LayneHaber · 2022-01-17T15:46:23Z

LayneHaber
Jan 17, 2022
Maintainer

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 · 2022-01-18T11:07:35Z

sanchaymittal
Jan 18, 2022

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.

5 replies

ArjunBhuptani Jan 18, 2022
Maintainer

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 Jan 18, 2022

@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 Jan 18, 2022
Maintainer Author

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!)

8000

ArjunBhuptani Jan 19, 2022
Maintainer

@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 Jan 20, 2022

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

LayneHaber · 2022-02-07T16:41:46Z

LayneHaber
Feb 7, 2022
Maintainer Author

No longer relevant in the new designs

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Removing Collaborative Cancellations #758

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments 5 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Removing Collaborative Cancellations #758

Uh oh!

LayneHaber Jan 17, 2022 Maintainer

Summary

Motivation

Proposed Solution

Tests

Outstanding Questions

Tasks

Replies: 2 comments · 5 replies

Uh oh!

Uh oh!

sanchaymittal Jan 18, 2022

Uh oh!

ArjunBhuptani Jan 18, 2022 Maintainer

Uh oh!

jakekidd Jan 18, 2022

Uh oh!

LayneHaber Jan 18, 2022 Maintainer Author

Uh oh!

Uh oh!

ArjunBhuptani Jan 19, 2022 Maintainer

Uh oh!

base0010 Jan 20, 2022

Uh oh!

LayneHaber Feb 7, 2022 Maintainer Author

LayneHaber
Jan 17, 2022
Maintainer

Replies: 2 comments 5 replies

sanchaymittal
Jan 18, 2022

ArjunBhuptani Jan 18, 2022
Maintainer

LayneHaber Jan 18, 2022
Maintainer Author

ArjunBhuptani Jan 19, 2022
Maintainer

LayneHaber
Feb 7, 2022
Maintainer Author